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!


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

-- Bandwidth and Colocation Provided by --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to