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

[Joshua Colp]

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.

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