The PJSIP Configuration Wizard

Been wanting to try the new PJSIP stack but finding the configuration a little daunting?  Then this blog post is for you!

While the basic PJSIP configuration objects (endpoint, aor, etc.) allow a great deal of flexibility and control they can also make configuring standard scenarios like ‘trunk’ and ‘user’ more complicated than similar sip.conf scenarios.  The PJSIP Configuration Wizard introduced in Asterisk 13.2 aims to ease that burden by providing a single object called ‘wizard’ that be used to configure most common PJSIP scenarios.

Here’s a typical example of a trunk to an ITSP configured in pjsip.conf:

[my-itsp]
type = endpoint
aors = my-itsp
outbound_auth = my-itsp-auth
context = default

[my-itsp]
type = aor
contact = sip:sip.my-itsp.net
qualify_frequency = 15

[my-itsp-auth]
type = auth
auth_type = userpass
username = my_username
password = my_password

[my-itsp-reg]
type = registration
outbound_auth = my-itsp-auth
server_uri = sip:sip.my-itsp.net
client_uri = sip:my_username@sip.my-itsp.net

[my-itsp-identify]
type = identify
endpoint = my-itsp
match = sip.my-itsp.net

In this scenario, it takes 5 objects (endpoint, aor auth, registration, identify) to define this one trunk and you’ll notice that some of the information is repeated in multiple objects.  There are certainly cases where having this flexibility is necessary but for many, especially when the same pattern needs to be repeated many times, it’s not.

Here’s the same scenario defined with the PJSIP Configuration Wizard in pjsip_wizard.conf:

[my-itsp]
type = wizard
sends_auth = yes
sends_registrations = yes
remote_hosts = sip.my-itsp.net
outbound_auth/username = my_username
outbound_auth/password = my_password
endpoint/context = default
aor/qualify_frequency = 15

A lot simpler, isn’t it?  The wizard automatically creates an endpoint with the same name as the object and the rest of the objects are created depending on the wizard’s parameters.  You’ll notice that some of the parameters names are simply ‘<name>’ and others are in the form of ‘<object>/<name>’.  The simple ones govern the wizard itself.  For instance, ‘sends_auth’ tells the wizard to create the auth object and add it to the endpoint’s ‘outbound_auth’ parameter, and ‘sends_registrations’ tells the wizard to create the outbound registration object.  The parameters qualified by ‘<object>’ are simply passed on to the object in question so ‘aor/qualify_frequency ‘  sets ‘qualify_frequency’ on the aor.  Some parameters like ‘remote_hosts’ are use by all the objects removing the need to specify the same value in each object.  If you use the Asterisk CLI ‘pjsip show’ commands, you’ll see that the wizard creates the same objects as those specified individually in pjsip.conf.  In fact, as far as the rest of Asterisk is concerned, they are identical.

Users/Phones are another common scenario: If you have a lot to configure you can use the wizard plus the power of the template feature common to all Asterisk configuration files:

[user-template](!)
type = wizard
accepts_registrations = yes
accepts_auth = yes
has_hint = yes
hint_context = DLPN_DialPlan1
hint_application = Dial(${HINT})
endpoint/context = default
aor/qualify_frequency = 15

[alice](user-template)
hint_exten = 1000
inbound_auth/username = alice
inbound_auth/password = alicespassword

[bob](user-template)
hint_exten = 1001
inbound_auth/username = bob
inbound_auth/password = bobspassword
Nifty, huh?
Want more information?  Visit the PJSIP Configuration Wizard page on the Asterisk Wiki

6 Responses

  1. Great! Now, if only I could stop at that than it would be near-perfect, but there’s like 20 other config files in /etc/asterisk and it’s far from obvious which ones are legacy leftovers due to distro maintainers slacking off and which ones are actually necessary.

    What’s the absolute bare minimum set of files which got to be in /etc/asterisk in order to make pjsip_wizard.conf from this blog post work?

  2. Excellent illustration but I was thinking on smth even smaller and directly connected to the example in this port:

    – 2 user’s endpoints and 1 trunk configured in pjsip_wizard.conf
    – user’s extensions are 1000 and 1001

    That’d cover needs of most beginners perfectly, but the natural expectation is that following is possible:
    – 1000 can call 1001
    – 1001 can call 1000
    – if 1000 calls anything else it goes to trunk
    – if 1001 calls anything else it goes to trunk

    AFAIK, in order to make this happen we need matching extensions.conf with simple dialplan and pjsip.conf with transport definition, maybe smth else I’ve forgotten about. If we’d like extras like echo-test and voicemail that would require couple of more config files etc.

  3. There’s nothing more to it than that. The rest is stuff you’d have to do for any Asterisk setup, like the dialplan, voicemail, etc. If you try it and find something, be sure to let us know!

  4. The things which seems confusing to me is DLPN_DialPlan1: is it supposed to be defined in extensions.conf? Also, what about hint_application – why do we define it here and not in dialplan?

  5. Btw, both “hint_context” and “hint_application” do not have counterparts in the example pjsip.conf you’re using so I think it would be helpful to explain it in a bit more details.

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?