Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sun, Sep 21, 2014 at 11:07 AM, Brad Watkins wrote: > I'm just throwing this out there, but what if the "pattern" (we'll use > that name for now, although I'm not sure I like it as the final name) could > itself define new types. Then, if you provided a standard config (i.e., > the sample conf

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

I'm just throwing this out there, but what if the "pattern" (we'll use that name for now, although I'm not sure I like it as the final name) could itself define new types. Then, if you provided a standard config (i.e., the sample config) which defined some set of standard types (phone, itsp/trunk,

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 4:44 PM, Joshua Colp wrote: > George Joseph wrote: > > > > 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 ev

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: 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. If it does n

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 3:13 PM, Joshua Colp wrote: > George Joseph wrote: > >> On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp > > wrote: >> >> George Joseph wrote: >> >> >> >> >> I was thinking that we probably don't want to create hard coded >> ob

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp mailto:jc...@digium.com>> wrote: George Joseph wrote: I was thinking that we probably don't want to create hard coded objects called "trunk", "user", etc. Instead let the user define the

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp wrote: > George Joseph wrote: > > > > >> 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

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: 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. These types result in underlying endpoint,

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 1:35 PM, Joshua Colp wrote: > George Joseph wrote: > >> On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp > > wrote: >> >> George Joseph wrote: >> >> >> >> >> Or separate objects from a config file perspective but >> implemented

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp mailto:jc...@digium.com>> wrote: George Joseph wrote: Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing t

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp wrote: > George Joseph wrote: > > > > >> Or separate objects from a config file perspective but implemented in >> pjsip_configuration with endpoint. >> > > Completely separate. Mixing the two defeats the purpose of having a clear > boundary. > > Ok, h

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing the two defeats the purpose of having a clear boundary. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 12:06 PM, George Joseph wrote: > On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp wrote: > >> George Joseph wrote: >> >> >> >> >>> 5. The idea of higher level concept configuration has been thrown >>> around as something to make this easier. I personally think this

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp wrote: > George Joseph wrote: > > > > >> 5. The idea of higher level concept configuration has been thrown >> around as something to make this easier. I personally think this >> sort of thing belongs there. A type=trunk, itsp, phone, etc.

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: 5. The idea of higher level concept configuration has been thrown around as something to make this easier. I personally think this sort of thing belongs there. A type=trunk, itsp, phone, etc. Lower level blocks remain the same and additional logic on top c

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

On Sat, Sep 20, 2014 at 10:33 AM, Joshua Colp wrote: > George Joseph wrote: > > > > >> My proposal is to allow registration/server_uri to be specified as a >> comma separated list or to be specified multiple times just like >> aor/contact and identify/match. This would allow us to manage only 1

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

George Joseph wrote: My proposal is to allow registration/server_uri to be specified as a comma separated list or to be specified multiple times just like aor/contact and identify/match. This would allow us to manage only 1 registration section in the same manner as aor and identify. A regi