<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 20, 2014 at 10:33 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Joseph wrote:<br>
<br>
<snip><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My proposal is to allow registration/server_uri to be specified as a<br>
comma separated list or to be specified multiple times just like<br>
aor/contact and identify/match.  This would allow us to manage only 1<br>
registration section in the same manner as aor and identify.  A<br>
registration would be "Registered" if at least 1 server was registered<br>
or I can add a "registration_state_<u></u>registered_at" variable similar to<br>
"device_state_busy_at" which would specify the minimum number of servers<br>
needed to be considered "Registered".  If you actually want 2<br>
registrations, nothing stops you from creating them.<br>
<br>
It seems like a minor issue but for me (and other folks I'm betting) the<br>
transition from chan_sip to chan_pjsip rests on getting tools, GUIs,<br>
scripts, etc. migrated.  That variable number of registrations is a pain<br>
to deal with.<br>
<br>
Josh had some issues with this approach on IRC and suggested bringing<br>
the proposal to the list for wider discussion.<br>
</blockquote>
<br>
I'll elaborate on why I dislike this:<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>The CLI and AMI could show individual server_uri status just like they do individual contact status in an aor.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br></blockquote><div> </div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I look forward to seeing what others think!<br></blockquote><div><br></div><div>Me too!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br></font></span></blockquote></div></div></div>