Skip to end of metadata
Go to start of metadata

Below are some sample configurations to demonstrate various scenarios with complete pjsip.conf files. To see examples side by side with old chan_sip config head to Migrating from chan_sip to res_pjsip. Explanations of the config sections found in each example can be found in PJSIP Configuration Sections and Relationships.

A tutorial on secure and encrypted calling is located in the Secure Calling section of the wiki.

An endpoint with a single SIP phone with inbound registration to Asterisk

 EXAMPLE CONFIGURATION
  • auth= is used for the endpoint as opposed to outbound_auth= since we want to allow inbound registration for this endpoint
  • max_contacts= is set to something non-zero as we want to allow contacts to be created through registration

 

On this Page

 

A SIP trunk to your service provider, including outbound registration

 EXAMPLE CONFIGURATION

Trunks are a little tricky since many providers have unique requirements. Your final configuration may differ from what you see here.

  • "contact=sip:203.0.113.1:5060", we don't define the user portion statically since we'll set that dynamically in dialplan when we call the Dial application.
    See the dialing examples in the section "Dialing using chan_pjsip" for more.

  • "outbound_auth=mytrunk", we use "outbound_auth" instead of "auth" since the provider isn't typically going to authenticate with us when calling, but we will probably
    have to authenticate when calling through them.

  • We use an identify object to map all traffic from the provider's IP as traffic to that endpoint since the user portion of their From: header may vary with each call.
  • This example assumes that sip.example.com resolves to 203.0.113.1
Icon

You can specify the transport type by appending it to the server_uri and client_uri parameters. e.g.:

[mytrunk]
type=registration
outbound_auth=mytrunk
server_uri=sip:sip.example.com\;transport=tcp
client_uri=sip:[email protected]\;transport=tcp
retry_interval=60

Multiple endpoints with phones registering to Asterisk, using templates

 EXAMPLE CONFIGURATION

We want to show here that generally, with a large configuration you'll end up using templates to make configuration easier to handle when scaling. This avoids having redundant code in every similar section that you create.

Obviously the larger your configuration is, the more templates will benefit you. Here we just break apart the endpoints with templates, but you could do that with any config section that needs instances with variation, but where each may share common settings with their peers.

  • No labels

12 Comments

  1. Max

    Are names like [auth6001] mandatory or I can simply use just [6001] as with aor, endpoint etc?

    Edit: Seems like the latter is the case.

    1. Rusty Newton

      That is answered here: PJSIP Configuration Sections and Relationships#SectionNames

      Thanks!

      1. Sunny

        But there is not mention anywhere that names like [auth6001] mandatory ?

        1. Rusty Newton

          No, there is not. However, I'm not sure I understand your statement as a question. The section linked is fairly explicit. You'll have to rephrase your question to be more clear if you think I'm not understanding.

          1. Sunny

            Actually my question was what Max has asked above that

            Are names like [auth6001] mandatory or I can simply use just [6001] as with aor, endpoint etc? 

            because I am also little bit confused because the link you shared above and other many articles I read on pjsip everywhere it is mentioned like auth+extension, can you shed some light on this?

            1. Rusty Newton

              This may be a language translation issue. As the article linked explicitly answers Max's question.

              "In most cases, you can name a section whatever makes sense to you. For example you might name a transport [transport-udp-nat] to help you remember how that section is being used.

              However, in some cases, (endpoint and aor types) the section name has a relationship to its function. In the case of endpoint and aor their names must match the user portion of the SIP URI in the "To" header for inbound SIP requests. The exception to that rule is if you have an identify section configured for that endpoint. In that case the inbound request would be matched by IP instead of against the user in the "To" header."

              I'm not sure how to explain it another way. You can name most PJSIP configuration objects anything you want. For endpoints and aors you need to name them based on the SIP users calling in, as explained on the wiki.

              You do not need to use an object type plus an extension number as the name, I'm not sure where you are reading that.

               

  2. Steven Haigh

    It may be worthwhile to change the contact line in the AOR record to match the server_uri in the registration section.

    It is not obvious from the example what this is actually meant to do or that the two values are related.

    1. Rusty Newton

      Hmm, the example says "This example assumes that sip.example.com resolves to 203.0.113.1"

      The values are not necessarily related. The contact or contacts may be different than the address we register to.

      1. Steven Haigh

        Agreed, but as you can supply both an FQDN or IP address to both the aor and the match values, for a normal example there would be no need to separate the config into hostname and IP address.

        1. Rusty Newton

          Good point and now that I can't remember why we had it different in this example.. I'll go ahead and change it up.

  3. Sunny

    Where to define the host in endpoint so that we can call outside from that peer/endpoint?

    1. Rusty Newton

      See the example configuration under:

      "A SIP trunk to your service provider, including outbound registration"

      On this page.

      Also see this other page: Dialing PJSIP Channels