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.

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

[mytrunk]
type = endpoint
aors = mytrunk
outbound_auth = mytrunk

[mytrunk]
type = aor
contact = sip:sip1.myitsp.com

[mytrunk]
type = auth
username = myuser
password = mypass

[mytrunk]
type = identify
endpoint = mytrunk
match = sip1.myitsp.com

[mytrunk]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip1.myitsp.com

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*(1)* to retrieve or modify the config.

Now add a backup server...

[mytrunk]
type = endpoint
aors = mytrunk
outbound_auth = mytrunk

[mytrunk]
type = aor
contact = sip:sip1.myitsp.com,sip:sip2.myitsp.com

[mytrunk]
type = auth
username = myuser
password = mypass

[mytrunk]
type = identify
endpoint = mytrunk
match = sip1.myitsp.com,sip2.myitsp.com

[mytrunk-reg1]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip1.myitsp.com

[mytrunk-reg2]
type = registration
endpoint = mytrunk
outbound_auth = mytrunk
server_uri = sip:sip2.myitsp.com

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.

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.

What do you think?

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

Reply via email to