----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4190/#review13911 -----------------------------------------------------------
branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24436> No longer needed. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24434> Let's clean this up a bit. "Unable to allocate an object of type '%s' with id '%s'" branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24435> Same here! "Unable to apply configuration to object of type '%s' with id '%s'" branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24437> This can be an ao2_ref down. It will always be non-NULL. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24438> While forgiving this would yield an incomplete variable list, causing the resulting object to (potentially) not get everything they've specified. From a user perspective this could be slightly hellish to try to figure out what is going on. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24433> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24432> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24431> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24430> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24429> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24428> Do an update and if that fails then a create. That removes the chance of the object failing to exist if queried during the change-over. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24427> This can go away. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24426> If you take into account my suggestion below about never deleting here then this logic can go away and some checks added around the changeset create, and further down. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24423> This introduces a race condition where the object may not be there for a brief period of time. I'd remove this code (it also simplifies things). branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24424> Is this is successful and last_config exists you may want to just remove the category from there if it exists. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24425> If you do what I say above about removing the category above you can simplify this quite a lot. Every category present here would not be present in the new config, so a retrieve and a delete can be done. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24421> This is a roundabout way to do this. Why not have an API function like apply_wizard_mapping that returns the wizard and wizard_data? How does this impact ordering? Where does this get placed in the wizard order? Is it at the start, at the end, etc. branches/12/res/res_pjsip_config_wizard.c <https://reviewboard.asterisk.org/r/4190/#comment24422> This doesn't clean up the object_type_wizards vector or the objects stored in the wizard. - Joshua Colp On Dec. 3, 2014, 11:42 p.m., George Joseph wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4190/ > ----------------------------------------------------------- > > (Updated Dec. 3, 2014, 11:42 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), create, replace or > delete the object types from the wizard definitions and add them to the > memory wizard using the callbacks saved in the previous step. > > RELOADABILITY: > > The new module itself cannot be reloaded or unloaded but there's no point to > that anyway. 'core reload' and 'module reload res_pjsip' work quite well > though which is much more important. 'core reload' is the preferred reload > mechanism over reloading specific pjsip modules because it reloads all > modules so modules such as res_pjsip_outbound_registration know to start > registration for newly discovered objects. > > 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 the '@pjsip_wizard' attribute. > > OTHER: > > This module does not use sorcery to read its pjsip_wizard.conf file. Since > this module implements a sorcery wizard, 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 428944 > branches/12/res/res_pjsip_config_wizard.c PRE-CREATION > branches/12/configs/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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
