> On Dec. 8, 2014, 5:52 a.m., Joshua Colp wrote: > > branches/12/res/res_pjsip_config_wizard.c, line 746 > > <https://reviewboard.asterisk.org/r/4190/diff/3/?file=69442#file69442line746> > > > > Is this is successful and last_config exists you may want to just > > remove the category from there if it exists. > > George Joseph wrote: > Adding and deleting an entire config wizard is straightforward. Changing > a wizard though could result in adds, changes and deletes to primitive > objects. If I remove a remote host for instance, this could result in a > change to an identify and aor and a delete of a registration. Or maybe I > change a phone from static to dynamic which would result in a change to aor > and a delete of identify. It's the deletes that are the problem. > > I think it's safer and more straightforward to clean a wizard out if > there's any change and rebuild it rather than trying to detect exactly what > changed. > > Joshua Colp wrote: > You can't delete everything and then add new stuff - that's not an atomic > operation from this level. You introduce a possibility where the old > configuration isn't there and the new one isn't.
True, and if we had commit/rollback capability it'd be easy. I'll give it a shot and see what happens though. - George ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4190/#review13911 ----------------------------------------------------------- On Dec. 3, 2014, 4: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, 4: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
