[asterisk-dev] [Code Review] 4190: res_pjsip_config_wizard: Allow streamlined configuration of common pjsip scenarios

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4190/#review13960
-----------------------------------------------------------

Ship it!


Ship It!

- Joshua Colp


On Dec. 10, 2014, 11:21 p.m., George Joseph wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4190/
> -----------------------------------------------------------
> 
> (Updated Dec. 10, 2014, 11:21 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The PJSIP Configuration Wizard allows for creation of simple pjsip scenarios like phone or trunk without having to directly specify individual endpoints, aors, auths, identifies or registrations.  The easiest way to demonstrate this is with an example or two from pjsip_wizard.conf.sample...
> 
> ;============EXAMPLE WIZARD CONFIGURATION FOR A PHONE=======================
> 
> ; This config would create an endpoint, aor with dynamic contact, inbound
> ; auth and a phoneprov object.
> 
> [myphone]
> type = wizard
> accepts_auth = yes
> accepts_registrations = yes
> transport = ipv4
> has_phoneprov = yes
> aor/max_contacts = 1
> inbound_auth/username = testname
> inbound_auth/password = test password
> endpoint/allow = ulaw
> endpoint/context = default
> phoneprov/MAC = 001122aa4455
> phoneprov/PROFILE = profile1
> 
> ;============EXAMPLE WIZARD CONFIGURATION FOR AN ITSP TRUNK=================
> 
> ; This ITSP has 2 servers available and requires registration.
> 
> ; This config would create an endpoint, an aor with 2 static contacts, an outbound
> ; auth, an identify with 2 matches, and 2 registrations.
> 
> [mytrunk]
> type = wizard
> sends_auth = yes
> sends_registrations = yes
> transport = ipv4
> ; The number of remote_hosts drives the number of contacts, matches and registrations.
> remote_hosts = sip1.myitsp.com:5060,sip2.myitsp.com:5060
> outbound_auth/username = testname
> outbound_auth/password = test password
> endpoint/allow = ulaw
> endpoint/context = default
> 
> pjsip_wizard.conf.sample has more details.
> 
> The history of the wizard approach can be found in the following 2 threads...
> 
> http://lists.digium.com/pipermail/asterisk-dev/2014-September/070426.html
> http://lists.digium.com/pipermail/asterisk-dev/2014-October/070616.html
> 
> THEORY OF OPERATION:
> 
> Load sequence...
> * Register as an ast_sorcery_global_observer.
> * When notified that res_pjsip has opened a sorcery instance, register as an ast_sorcery_instance_observer for res_pjsip.
> * When notified that an object_type has been registered, call ast_sorcery_apply_wizard_mapping to add a memory wizard to the object type.
> * When notified that the memory wizard has been mapped, save its callbacks for later use.
> * When notified that an object type has been loaded or reloaded, parse pjsip_wizard.conf (detecting adds, changed and deletes), then take appropriate action to add, update or delete primitive pjsip objects.
> 
> RE/LOADABILITY:
> 
> The new module itself cannot be reloaded but there's no point to that anyway.  'core reload' and 'module reload res_pjsip'/'pjsip reload' work quite well which is much more important.  If the module is unloaded, all of the pjsip objects it was responsible for are removed.  If the module is subsequently loaded again, a reload of res_pjsip will occur and all the objects will come back again.
> 
> BACKWARDS COMPATIBILITY:
> 
> This module does not change any existing functionality.  Once created by the wizard, pjsip objects are indistinguishable from ones created discretely other than the addition of a '@pjsip_wizard' attribute which indicates the name of the wizard that created them.
> 
> OTHER:
> 
> This module does not use sorcery to read its pjsip_wizard.conf file.  Doing so would have created 'chicken and egg' scenarios which would have been complex to solve.  It does use the standard config mechanism though so you can use extconfig.conf to get the config from an external source.
> 
> res_pjsip_phoneprov_provider needed a little rearranging to work with the wizard.  No other modules were modified.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/res_pjsip_phoneprov_provider.c 429349 
>   branches/12/res/res_pjsip_config_wizard.c PRE-CREATION 
>   branches/12/configs/samples/pjsip_wizard.conf.sample PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4190/diff/
> 
> 
> Testing
> -------
> 
> Test suite tests are available that use the wizard to create objects and AMI to read the results.  The results are indistinguishable except the for '@pjsip_wizard' attribute.
> 
> I've converted my own PBX to use the wizard approach and phones and trunks operate normally.
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141215/1d4d4016/attachment-0001.html>