<div dir="ltr"><div>In the process of getting my GUI and real customers up on PJSIP I've come across a few things that could work better for me.  One of them is the configuration process for ITSP trunks, specifically those that require registration and have more than 1 server.   </div><div><br></div><div>In a simple single-server scenario, a trunk would need 1 endpoint, 1 aor, 1 outbound_auth, 1 identify and 1 registration.  Leaving out variables not needed for the example...</div><div><br></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = endpoint</font></div><div><font face="courier new, monospace" size="1">aors = mytrunk</font></div><div><font face="courier new, monospace" size="1">outbound_auth = mytrunk</font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = aor</font></div><div><font face="courier new, monospace" size="1">contact = sip:<a href="http://sip1.myitsp.com">sip1.myitsp.com</a></font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = auth</font></div><div><font face="courier new, monospace" size="1">username = myuser</font></div><div><font face="courier new, monospace" size="1">password = mypass</font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = identify</font></div><div><font face="courier new, monospace" size="1">endpoint = mytrunk</font></div><div><font face="courier new, monospace" size="1">match = <a href="http://sip1.myitsp.com">sip1.myitsp.com</a></font></div><div><font face="courier new, monospace" size="1"><br></font></div><font face="courier new, monospace" size="1">[mytrunk]</font><div><font face="courier new, monospace" size="1">type = registration</font></div><div><div><font face="courier new, monospace" size="1">endpoint = mytrunk</font></div><div><font face="courier new, monospace" size="1">outbound_auth = mytrunk</font></div><div><font face="courier new, monospace" size="1">server_uri = sip:<a href="http://sip1.myitsp.com">sip1.myitsp.com</a><br></font></div><div><br></div><div>A little more verbose than chan_sip but pretty straightforward.   I used the same name for all category/context/sections on purpose.  It makes grouping everything that makes up the trunk a lot easier especially if you're using scripts or the AMI<font size="1"><b>(1)</b></font> to retrieve or modify the config.  </div><div><br></div><div>Now add a backup server...</div><div><br></div><div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = endpoint</font></div><div><font face="courier new, monospace" size="1">aors = mytrunk</font></div><div><font face="courier new, monospace" size="1">outbound_auth = mytrunk</font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = aor</font></div><div><font face="courier new, monospace" size="1">contact = sip:<a href="http://sip1.myitsp.com">sip1.myitsp.com</a>,sip:<a href="http://sip2.myitsp.com">sip2.myitsp.com</a></font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = auth</font></div><div><font face="courier new, monospace" size="1">username = myuser</font></div><div><font face="courier new, monospace" size="1">password = mypass</font></div><div><font face="courier new, monospace" size="1"><br></font></div><div><font face="courier new, monospace" size="1">[mytrunk]</font></div><div><font face="courier new, monospace" size="1">type = identify</font></div><div><font face="courier new, monospace" size="1">endpoint = mytrunk</font></div><div><font face="courier new, monospace" size="1">match = <a href="http://sip1.myitsp.com">sip1.myitsp.com</a>,<a href="http://sip2.myitsp.com">sip2.myitsp.com</a></font></div><div><font face="courier new, monospace" size="1"><br></font></div><font face="courier new, monospace" size="1">[mytrunk-reg1]</font><div><font face="courier new, monospace" size="1">type = registration</font></div><div><div><font face="courier new, monospace" size="1">endpoint = mytrunk</font></div><div><font face="courier new, monospace" size="1">outbound_auth = mytrunk</font></div><div><font face="courier new, monospace" size="1">server_uri = sip:<a href="http://sip1.myitsp.com">sip1.myitsp.com</a></font></div></div></div><div><font face="courier new, monospace" size="1"><br></font></div><div><div><font face="courier new, monospace" size="1">[mytrunk-reg2]</font><div><font face="courier new, monospace" size="1">type = registration</font></div><div><div><font face="courier new, monospace" size="1">endpoint = mytrunk</font></div><div><font face="courier new, monospace" size="1">outbound_auth = mytrunk</font></div><div><font face="courier new, monospace" size="1">server_uri = sip:<a href="http://sip2.myitsp.com">sip2.myitsp.com</a></font></div></div></div><div><br></div></div><div>I still have 1 endpoint, 1 aor, 1 auth, 1 identify but now I need 2 registrations because you can only have 1 server_uri in a registration,  and they need special names so they don't conflict.   The only thing different is the server_uri and just like contact and match, they're interchangeable in this scenario.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Josh had some issues with this approach on IRC and suggested bringing the proposal to the list for wider discussion.</div><div><br></div><div>What do you think?</div><div><br></div><div>-----------------------</div><div>(1):  Today you can't use AMI GetConfig/GetConfigJSON and UpdateConfig with a config file with multiple contexts with the same name.  I'll have patches for that shortly which eventually will also allow res_sorcery_config to write back to its files. </div><div><br></div><div><br></div></div></div>