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
