As we talked about in #asterisk-dev, I like the proposal generally and prefer the second style specifically. Just as a matter of eventual documentation, it'd be nice to see examples using a hierarchy of templates that shows how to minimize duplication of configuration.
- Brad On Wed, Oct 1, 2014 at 8:54 PM, George Joseph <[email protected]> wrote: > This is a followup to the discussion we had in this thread... > Opinions Needed: PJSIP Outboud Registration with multiple server_uris > <http://lists.digium.com/pipermail/asterisk-dev/2014-September/070426.html> > > I started with wanting to allow multiple server_uris in a single > registration object but where we wound up was with the creation of a new > module that would provide a configuration layer on top of the existing > pjsip configuration mechanism. The purpose of the layer is to make > configuration of the most common pjsip scenarios, and the transition from > chan_sip, easier. As a happy side effect, it also allows easier > manipulation of pjsip contifuration from scripts and AMI. > > Basically, the new module creates a 'wizard' object that lets you > configure common scenarios like 'phone' and 'trunk' with a single object > rather than defining a separate endpoint, aor, identify, auth, > registration, etc. It does NOT replace or alter the existing object > model. The wizard in fact just creates all the normal objects behind the > scenes. > > Showing examples will be much easier than trying to describe it. > > PJSIP Configuration Wizard Proposal 1 > <https://gist.github.com/gtjoseph/f11e1cdf261d93ef5516#file-pjsip_wizard_1-conf> > PJSIP Configuration Wizard Proposal 2 > <https://gist.github.com/gtjoseph/e09978f8085091513115#file-pjsip_wizard_2-conf> > > The difference between the 2 proposals is that the first one actually > defines types called 'trunk', 'phone', and 'phone-static' which are used > later in the config. After staring at it a while though I thought there's > really no benefit to the types if you use templates. Hence the second > proposal which I favor. To see the real benefit of the whole approach, > look down at sections starting at [myitsp]. > > I know there are going to be questions and controversy so fire away! > > george > > > > > > > > > > > -- > _____________________________________________________________________ > -- 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 >
-- _____________________________________________________________________ -- 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
