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