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

[George Joseph]

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

(Updated Nov. 13, 2014, 5:35 p.m.)


Status
------

This change has been discarded.


Review request for Asterisk Developers, Joshua Colp, Marquis, 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.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
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.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:

N.B.:  There are two kinds of wizards referenced here:  The existing sorcery wizards which provide the storage back ends like res_sorcery_config and res_sorcery_realtime, and this new pjsip config wizard.  The new module implements both a new sorcery wizard and the pjsip wizard.

The wizard is implemented in a single module but did require a few tweaks to other res_pjsip modules and sorcery itself.  There are 2 parts to this module, the config wizard and the sorcery wizard.  When the module loads, the config wizard part loads pjsip.conf and pulls in all of the 'wizard' object types.  Assuming they're all semantically valid, the module then registers itself as a sorcery wizard.  The sorcery wizard part provides a sorcery back end almost exactly like res_sorcery_memory.  A change was made to each of the pjsip modules so that as they load, they apply wizard mappings from not only sorcery.conf and pjsip.conf, but also from the new 'pjsip_wizard' sorcery wizard.  The result is that then they call ast_sorcery_load_object, sorcery also pulls objects from the pjsip_wizard after it's pulled them from pjsip.conf.  That in turn causes pjsip_wizard to create auths, aors, endpoints, identifies, registrations and phoneprovs from the data it collected earlier.  pjsip is none the wiser about where the objects came from and all AMI, ARI, CLI etc. operate as normal.

SUMMARY OF CHANGES MADE:

* The new res_pjsip_config_wizard module was created.
* An existing internal sorcery api was exposed as ast_sorcery_apply_wizard_mapping to allow the addition of a new wizard to an object type.  The underlying plumbing was already there.
* config_auth, location, pjsip_configuration, res_pjsip_endpoint_identifier_ip, res_pjsip_outbound_registration and res_pjsip_phoneprov_provider were all modified to call ast_sorcery_apply_wizard_mapping after calling ast_sorcery_apply_default.
*  res_pjsip_phoneprov_provider needed a little more work to be compatible.

RELOADABILITY:

I've done my best to make the new module properly unload and reload but there are issues with the rest of the pjsip modules that make this tricky. Further work will be needed for consistent module operations across all of pjsip.

BACKWARDS COMPATIBILITY:

This module does not change any existing functionality.  Discrete objects and wizards may both exist in a single pjsip.conf file.  If the res_pjsip_config_wizard module isn't loaded, the wizard types will just be ignored.  If the module is loaded but there are no wizard types in pjsip.conf, it stays loaded but empty.  Once created by the wizard, pjsip objects are indistinguishable from ones created discretely.

OTHER:

Even though the new module provides a sorcery wizard, it can get its own wizard objects from other wizards like realtime or astdb using sorcery.conf.


Diffs
-----

  branches/12/res/res_pjsip_phoneprov_provider.c 427761 
  branches/12/res/res_pjsip_outbound_registration.c 427761 
  branches/12/res/res_pjsip_endpoint_identifier_ip.c 427761 
  branches/12/res/res_pjsip_config_wizard.c PRE-CREATION 
  branches/12/res/res_pjsip/pjsip_configuration.c 427761 
  branches/12/res/res_pjsip/location.c 427761 
  branches/12/res/res_pjsip/config_auth.c 427761 
  branches/12/main/sorcery.c 427761 
  branches/12/include/asterisk/sorcery.h 427761 
  branches/12/configs/pjsip.conf.sample 427761 

Diff: https://reviewboard.asterisk.org/r/4165/diff/


Testing
-------

Test suite tests are in development that will use the wizard to create objects and AMI to read the results.  For instance, endpoint objects created by the wizard should be indistinguishable from endpoint objects created directly.  They will be posted shortly.

I've converted my own PBX to use the wizard approach and phones and trunks operate normally.

The CLI and AMI return results indistinguishable from discretely defined objects.


Thanks,

George Joseph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141114/e57af7e4/attachment.html>