On Sat, Sep 20, 2014 at 3:13 PM, Joshua Colp <[email protected]> wrote:
> George Joseph wrote: > >> On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp <[email protected] >> <mailto:[email protected]>> wrote: >> >> George Joseph wrote: >> >> <snip> >> >> >> I was thinking that we probably don't want to create hard coded >> objects >> called "trunk", "user", etc. Instead let the user define the >> patterns >> that suit them. >> >> >> It would be much more approachable for a user with specific types. >> >> >> Is this agreement on letting the user define the patterns (with samples >> provides) or are you saying we should hardcode types? There are enough >> variations in the patterns that I don't think we could create viable >> 'trunk', 'user', etc. objects. I'd make this a separate config >> (pjsip_express.conf or something) with a default set of pattern >> definitions. >> > > I'm saying for making it easier to configure PJSIP for users there could > be hardcoded types which represent the common types that users need. If > more control is required than the lower level detailed ones can be used. It > is certainly possible to have 'phone' and 'trunk' types which are useful > for a good percentage. > > Your pattern idea I would say is an alternative way for doing it, but is > still more complicated than distinct types and requires explanation. > How about we use the pattern approach but compile in patterns for trunk and user. There are lots of minor differences between ITSPs and phones and I just worry that in the quest to create something for everyone we create something that's useful to no one. > > Given the following (even without documentation) could someone coming from > sip.conf understand it? > > [1000] > type=phone > secret=notverysecret > context=trusted > disallow=all > allow=g722 > mailbox=1000 > > I err on the side of yes. That's what I think is needed. Heck, it's hard > enough to get people to realize they can use templates. > > I love templates so much that I enhanced manager and config so you read and write templates via AMI GetConfig and UpdateConfig. If we compile in basic patterns it could be as simple as [1000] type = composite ; ok, maybe composite and pattern aren't good names. pattern = phone ; built-in pattern incoming_password = notverysecret context = trusted disallow = all allow = g722 mailboxes = 1000 Are you OK with a separate config file? It would make manipulating it easier since there'd be no duplicate section names.
-- _____________________________________________________________________ -- 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
