On Sat, Sep 20, 2014 at 10:33 AM, Joshua Colp <jc...@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 > >
-- _____________________________________________________________________ -- 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
