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

  • 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


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

  • "contact=sip:", 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 resolves to

Multiple endpoints with phones registering to Asterisk, using templates


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


  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.

  2. 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. Hmm, the example says "This example assumes that resolves to"

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

      1. 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. 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.