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

[George Joseph]

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 config) which defined some set of standard types (phone,
> itsp/trunk, whatever) you could have configurations with semantics similar
> to what Josh originally proposed.  It also means a user of Asterisk can
> look at the config for the pattern and both see what it's doing under the
> hood (vs. being in the code somewhere) and also modify it for their own
> needs if they'd like to.
>
> Anyway, just a thought.
>
> Makes sense to me.


>
>
-- 
_
-- 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

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

[Brad Watkins]

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, whatever) you could have configurations with semantics similar
to what Josh originally proposed.  It also means a user of Asterisk can
look at the config for the pattern and both see what it's doing under the
hood (vs. being in the code somewhere) and also modify it for their own
needs if they'd like to.

Anyway, just a thought.


On Sat, Sep 20, 2014 at 8:13 PM, George Joseph 
wrote:

> 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 everyone we
>>> create something that's useful to no one.
>>>
>>
>> If it does not impact any of the existing code and is easy for a user,
>> then sure. That being said... get feedback any way you can before doing
>> anything. This is a complicated area.
>>
>>>
>>> Unfortunately, it looks like everyone took Saturday off.   What gives?
>  :)
>
>
> --
> _
> -- 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

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

[George Joseph]

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 everyone we
>> create something that's useful to no one.
>>
>
> If it does not impact any of the existing code and is easy for a user,
> then sure. That being said... get feedback any way you can before doing
> anything. This is a complicated area.
>
>>
>> Unfortunately, it looks like everyone took Saturday off.   What gives?  :)
-- 
_
-- 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

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

[Joshua Colp]

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 not impact any of the existing code and is easy for a user, 
then sure. That being said... get feedback any way you can before doing 
anything. This is a complicated area.





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.


Yes.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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
>> 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

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

[Joshua Colp]

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
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.


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.


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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 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.


> These types result in underlying endpoint, identify, outbound
> registrations, etc existing but that fact is an underlying detail they
> don't worry or care about.
>
>
Exactly.
-- 
_
-- 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

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

[Joshua Colp]

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, identify, outbound registrations, 
etc existing but that fact is an underlying detail they don't worry or 
care about.


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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 in
>> pjsip_configuration with endpoint.
>>
>>
>> Completely separate. Mixing the two defeats the purpose of having a
>> clear boundary.
>>
>> Ok, how about this...   2 new object types called "composite" and
>> "pattern" (or whatever) implemented in a separate res_pjsip_* module
>>
>> [mytrunk]
>> type = composite
>> pattern = trunk
>> etc...
>>
>> [trunk]
>> type = pattern
>> register = yes
>> contacts = static
>> outbound_auth = yes
>> inbound_auth = no
>> identify = yes
>>
>>
> I don't understand the naming or what they mean at first glance ^_^
>
> 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.

So, define a pattern first...

[trunk-pattern]
type = pattern
contacts = static   ; would cause a contact line to appear in the aor
; for each server
register = yes  ; would cause a registration object to be created for
each
; server
outbound_auth = yes ; would cause an auth object to be created which the
; endpoint would reference as outbound_auth
inbound_auth = no   ; would do the same thing for endpoint/auth
identify = yes  ; would cause an identify object to be created with a
; match for each server
Actually, the pattern could specify how to construct other variables...
client_uri = sip:%OU@%S
contact = sip:%S
server_uri = sip:%S

Now for each trunk...

[mytrunk]
type = composite
pattern = trunk-pattern
server = sip1.itsp.com
server = sip2.itsp.com
outbound_username = myusername
outbound_password = mypassword

would be the equivalent of...

[mytrunk]
type = endpoint
aors = mytrunk
outbound_auth = mytrunk-auth

[mytrunk]
type = aor
contact = sip:sip1.itsp.com
contact = sip:sip2.itsp.com

[mytrunk-auth]
type = auth
username = myusername
password = mypassword

[mytrunk-id]
type = identify
endpoint = mytrunk
match = sip1.itsp.com
match = sip2.itsp.com

[myrunk-reg-1]
type = registration
endpoint = mytrunk
client_uri = sip:myusern...@sip1.itsp.com
server_uri = sip:sip1.itsp.com

[myrunk-reg-2]
type = registration
endpoint = mytrunk
client_uri = sip:myusern...@sip2.itsp.com
server_uri = sip:sip2.itsp.com
-- 
_
-- 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

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

[Joshua Colp]

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 the two defeats the purpose of having a
clear boundary.

Ok, how about this...   2 new object types called "composite" and
"pattern" (or whatever) implemented in a separate res_pjsip_* module

[mytrunk]
type = composite
pattern = trunk
etc...

[trunk]
type = pattern
register = yes
contacts = static
outbound_auth = yes
inbound_auth = no
identify = yes



I don't understand the naming or what they mean at first glance ^_^

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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, how about this...   2 new object types called "composite" and "pattern"
(or whatever) implemented in a separate res_pjsip_* module

[mytrunk]
type = composite
pattern = trunk
etc...

[trunk]
type = pattern
register = yes
contacts = static
outbound_auth = yes
inbound_auth = no
identify = yes
-- 
_
-- 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

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

[Joshua Colp]

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 - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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
>>> sort of thing belongs there. A type=trunk, itsp, phone, etc. Lower
>>> level blocks remain the same and additional logic on top can be
>>> added to handle this sort of thing.
>>>
>>> Are you thinking like users.conf?  I thought you guys wanted that to die
>>> a horrible death. :)   Seriously though, are you thinking along the
>>> lines of a new composite pjsip configuration object that creates the
>>> base objects behind the scenes?   If so, that'd solve a lot and I could
>>> start working on it right now.  I just thought you guys were shying away
>>> from these types of things.
>>>
>>
>> As base objects it's a bad idea. As a single object to rule them all (a
>> user) it's also a complicated/bad idea. As higher level concepts which
>> represent things that people are familiar with they're fine.
>>
>> Since endpoint really contains most of the detailed config parameters,
> would you see enhancements to endpoint that allow direct specification of
> simple things like username, password, contact, etc.  or really a separate
> object like trunk, user, etc.?   I'm guessing the latter but the former
> would be a lot easier to implement.
>
> Or separate objects from a config file perspective but implemented in
pjsip_configuration with endpoint.
-- 
_
-- 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

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

[George Joseph]

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. Lower
>> level blocks remain the same and additional logic on top can be
>> added to handle this sort of thing.
>>
>> Are you thinking like users.conf?  I thought you guys wanted that to die
>> a horrible death. :)   Seriously though, are you thinking along the
>> lines of a new composite pjsip configuration object that creates the
>> base objects behind the scenes?   If so, that'd solve a lot and I could
>> start working on it right now.  I just thought you guys were shying away
>> from these types of things.
>>
>
> As base objects it's a bad idea. As a single object to rule them all (a
> user) it's also a complicated/bad idea. As higher level concepts which
> represent things that people are familiar with they're fine.
>
> Since endpoint really contains most of the detailed config parameters,
would you see enhancements to endpoint that allow direct specification of
simple things like username, password, contact, etc.  or really a separate
object like trunk, user, etc.?   I'm guessing the latter but the former
would be a lot easier to implement.
-- 
_
-- 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

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

[Joshua Colp]

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 can be
added to handle this sort of thing.

Are you thinking like users.conf?  I thought you guys wanted that to die
a horrible death. :)   Seriously though, are you thinking along the
lines of a new composite pjsip configuration object that creates the
base objects behind the scenes?   If so, that'd solve a lot and I could
start working on it right now.  I just thought you guys were shying away
from these types of things.


As base objects it's a bad idea. As a single object to rule them all (a 
user) it's also a complicated/bad idea. As higher level concepts which 
represent things that people are familiar with they're fine.


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

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
>> registration section in the same manner as aor and identify.  A
>> registration would be "Registered" if at least 1 server was registered
>> or I can add a "registration_state_registered_at" variable similar to
>> "device_state_busy_at" which would specify the minimum number of servers
>> needed to be considered "Registered".  If you actually want 2
>> registrations, nothing stops you from creating them.
>>
>> It seems like a minor issue but for me (and other folks I'm betting) the
>> transition from chan_sip to chan_pjsip rests on getting tools, GUIs,
>> scripts, etc. migrated.  That variable number of registrations is a pain
>> to deal with.
>>
>> Josh had some issues with this approach on IRC and suggested bringing
>> the proposal to the list for wider discussion.
>>
>
> I'll elaborate on why I dislike this:
>
> 1. It's overloading the outbound registration object to actually mean
> outbound registrations. This complicates the implementation and from a user
> perspective becomes harder to explain. Someone doesn't have to use it, but
> if they see it... they will... potentially without knowing what it means.
>
> 2. From a first glance and seeing the type as outbound registration I
> would expect that someone would think of it as an ordered failover list. If
> I can't register to the first then I'll try the second and so on. This is
> what some phones do. That's not what this would do.
>

I take your point but PJSIP configuration is so much more complex than SIP
configuration that there are lots of things that are going to trip people
up.  I don't think this one little point will matter.  I've been in the
code for a year and I'm still finding things I though worked one way but
really worked another.


>
> 3. What it means to register to multiple URIs and how that should be
> interpreted is really environment specific. You've mentioned making what
> the cumulative result is configurable but knowing what failed and what
> succeeded individually is still important. It may not be for some ITSPs, it
> may be for others. If addressed individually you get this information
> already and it can be interpreted.
>

The CLI and AMI could show individual server_uri status just like they do
individual contact status in an aor.


>
> 4. I'm hesitant to push this into the outbound registration module as the
> solution. I'm all for making things easier but having these lower level
> blocks as simple and direct as possible is valuable. Trying not to cross
> the line is hard.
>

Agreed.


>
> 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 can be added to handle this sort of
> thing.
>
>
Are you thinking like users.conf?  I thought you guys wanted that to die a
horrible death. :)   Seriously though, are you thinking along the lines of
a new composite pjsip configuration object that creates the base objects
behind the scenes?   If so, that'd solve a lot and I could start working on
it right now.  I just thought you guys were shying away from these types of
things.


> I look forward to seeing what others think!
>

Me too!


>
> Cheers,
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
-- 
_
-- 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

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

[Joshua Colp]

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
registration would be "Registered" if at least 1 server was registered
or I can add a "registration_state_registered_at" variable similar to
"device_state_busy_at" which would specify the minimum number of servers
needed to be considered "Registered".  If you actually want 2
registrations, nothing stops you from creating them.

It seems like a minor issue but for me (and other folks I'm betting) the
transition from chan_sip to chan_pjsip rests on getting tools, GUIs,
scripts, etc. migrated.  That variable number of registrations is a pain
to deal with.

Josh had some issues with this approach on IRC and suggested bringing
the proposal to the list for wider discussion.


I'll elaborate on why I dislike this:

1. It's overloading the outbound registration object to actually mean 
outbound registrations. This complicates the implementation and from a 
user perspective becomes harder to explain. Someone doesn't have to use 
it, but if they see it... they will... potentially without knowing what 
it means.


2. From a first glance and seeing the type as outbound registration I 
would expect that someone would think of it as an ordered failover list. 
If I can't register to the first then I'll try the second and so on. 
This is what some phones do. That's not what this would do.


3. What it means to register to multiple URIs and how that should be 
interpreted is really environment specific. You've mentioned making what 
the cumulative result is configurable but knowing what failed and what 
succeeded individually is still important. It may not be for some ITSPs, 
it may be for others. If addressed individually you get this information 
already and it can be interpreted.


4. I'm hesitant to push this into the outbound registration module as 
the solution. I'm all for making things easier but having these lower 
level blocks as simple and direct as possible is valuable. Trying not to 
cross the line is hard.


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 can be added to handle this sort of 
thing.


I look forward to seeing what others think!

Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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

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

[George Joseph]

In the process of getting my GUI and real customers up on PJSIP I've come
across a few things that could work better for me.  One of them is the
configuration process for ITSP trunks, specifically those that require
registration and have more than 1 server.

In a simple single-server scenario, a trunk would need 1 endpoint, 1 aor, 1
outbound_auth, 1 identify and 1 registration.  Leaving out variables not
needed for the example...

[mytrunk]
type = endpoint
aors = mytrunk
outbound_auth = mytrunk

[mytrunk]
type = aor
contact = sip:sip1.myitsp.com

[mytrunk]
type = auth
username = myuser
password = mypass

[mytrunk]
type = identify
endpoint = mytrunk
match = sip1.myitsp.com

[mytrunk]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip1.myitsp.com

A little more verbose than chan_sip but pretty straightforward.   I used
the same name for all category/context/sections on purpose.  It makes
grouping everything that makes up the trunk a lot easier especially if
you're using scripts or the AMI*(1)* to retrieve or modify the config.

Now add a backup server...

[mytrunk]
type = endpoint
aors = mytrunk
outbound_auth = mytrunk

[mytrunk]
type = aor
contact = sip:sip1.myitsp.com,sip:sip2.myitsp.com

[mytrunk]
type = auth
username = myuser
password = mypass

[mytrunk]
type = identify
endpoint = mytrunk
match = sip1.myitsp.com,sip2.myitsp.com

[mytrunk-reg1]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip1.myitsp.com

[mytrunk-reg2]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip2.myitsp.com

I still have 1 endpoint, 1 aor, 1 auth, 1 identify but now I need 2
registrations because you can only have 1 server_uri in a registration,
 and they need special names so they don't conflict.   The only thing
different is the server_uri and just like contact and match, they're
interchangeable in this scenario.

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 registration would be
"Registered" if at least 1 server was registered or I can add a
"registration_state_registered_at" variable similar to
"device_state_busy_at" which would specify the minimum number of servers
needed to be considered "Registered".  If you actually want 2
registrations, nothing stops you from creating them.

It seems like a minor issue but for me (and other folks I'm betting) the
transition from chan_sip to chan_pjsip rests on getting tools, GUIs,
scripts, etc. migrated.  That variable number of registrations is a pain to
deal with.

Josh had some issues with this approach on IRC and suggested bringing the
proposal to the list for wider discussion.

What do you think?

---
(1):  Today you can't use AMI GetConfig/GetConfigJSON and UpdateConfig with
a config file with multiple contexts with the same name.  I'll have patches
for that shortly which eventually will also allow res_sorcery_config to
write back to its files.
-- 
_
-- 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