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