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

[George Joseph]

On Sat, Sep 20, 2014 at 10:33 AM, Joshua Colp <jcolp at digium.com> wrote:

> George Joseph wrote:
>
> <snip>
>
>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140920/7a60855a/attachment.html>