The PJSIP Configuration Wizard (module
res_pjsip_config_wizard) is a new feature in Asterisk 13.2.0. While the basic basic
chan_pjsip configuration objects (endpoint, aor, etc.) allow a great deal of flexibility and control they can also make configuring standard scenarios like like
trunk and and
user more complicated than than
users.conf. The PJSIP Configuration Wizard aims to ease that burden by providing a single object called 'wizard' that be used to configure most common common
The following configurations demonstrate a simple ITSP scenario.
Both produce the same result. In fact, the wizard creates standard chan_pjsip objects behind the scenes. In the above example...
- An endpoint and aor are created with the same name as the wizard.
- The 'endpoint/context' and 'aor/qualify_fequency' parameters are added to them.
- 'remote_hosts' captures the remote host for all objects.
- A contact for the aor is created for each remote host.
- 'sends_auth = yes' causes an auth object to be created.
- 'outbound_auth/username' and 'outbound_auth/password' are added to it.
- An outbound_auth line is added to the endpoint.
- 'sends_registrations = yes' causes a registration object to be created.
- An outbound_auth line is added to the registration.
- The server_uri and client_uri are constructed using the remote host and username.
- An identify object is created and a match is added for each remote host.
|type||Must be 'wizard'|
Will create an outbound auth object for the endpoint and
(default = "no")
Will create an inbound auth object for the endpoint.
(default = "no")
Will create an outbound registration object for each
A comma separated list of remote hosts in the form of
The transport to use for the endpoint and registrations
The pattern used to construct the registration
The pattern used to construct the registration client_uri.
The pattern used to construct the aor contact.
Will create a phoneprov object. If yes, both phoneprov/MAC and phoneprov/PROFILE
|<object>/<parameter>||These parameters are passed unmodified to the native object.|
- Wizards must be defined in 'pjsip_wizard.conf'.
- An endpoint and aor are created for each wizard.
- The endpoint and aor are named the same as the wizard.
- Parameters are passed to them using the 'endpoint/' and 'aor/' prefixes.
- A contact is added to the aor for each remote host using the contact_pattern.
- 'sends_auth' causes an 'auth' object to be created.
- The name will be '<wizard_name>-oauth'.
- Parameters are passed to it using the 'outbound_auth/' prefix.
- The endpoint automatically has an 'outbound_auth' parameter added to it.
- Registrations automatically have an 'outbound_auth' parameter added to them (if registrations are created, see below).
- 'accepts_auth' causes an 'auth' object to be created.
- The name will be '<wizard_name>-iauth'.
- Parameters are passed to it using the 'inbound_auth/' prefix.
- The endpoint automatically has an 'auth' parameter added to it.
- 'sends_registrations' causes an outbound registration object to be created for each remote host.
- The name will be '<wizard_name>-reg-<n>' where n starts at 0 and increments by 1 for each remote host.
- Parameters are passed to them using the 'registration/' prefix.
- You should not use a wizard in situations whereyou need to pass different parameters to each registration.
- 'server_uri' and 'client_uri' are constructed using their respective patterns using the remote host and 'outbound_auth/username'.
- If 'accepts_registrations' is specified, 'remote_hosts' must NOT be specified and no contacts are added to the aor. This causes registrations to be accepted.
- If 'accepts_registrations' is NOT specified or set to 'no', then an identify object is created to match incoming requests to the endpoint.
- Parameters are passed to it using the 'identify/' prefix although there really aren't any to pass.
- If 'has_phoneprov' is specified, a phoneprov object object is created.
- The name will be '<wizard_name>-phoneprov'.
- Both 'phoneprov/MAC' and 'phoneprov/PROFILE' must be specified.
- All created objects must pass the same edit criteria they would have to pass if they were specified discretely.
- All created objects will have a '@pjsip_wizard=<wizard_name>' parameter added to them otherwise they are indistinguishable from discretely created ones.
- All created object are visible via the CLI and AMI as though they were created discretely.
- Wizard created objects can co-exist with discretely created objects.
- There can be no name collisions between wizard created objects and discretely created objects.
This example demonstrates the power of both wizards and templates.
Once the template is created, adding a new phone could be as simple as creating a wizard object
Of course, you can override ANYTHING in the wizard object or specify everything and not use templates at all.
Trunk to an ITSP requiring registration:
This is an example of trunks to 2 different ITSPs each of which has a primary and
It also shows most of the endpoint and aor parameters being left at their defaults.
In this scenario, each wizard object takes the place of an endpoint, aor, auth,
Trunk between trusted peers:
This one's even simpler. The 'sends_' and 'accepts_' parameters all default to 'no' so you don't really