Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
I'm just throwing this out there, but what if the pattern (we'll use that name for now, although I'm not sure I like it as the final name) could itself define new types. Then, if you provided a standard config (i.e., the sample config) which defined some set of standard types (phone, itsp/trunk, whatever) you could have configurations with semantics similar to what Josh originally proposed. It also means a user of Asterisk can look at the config for the pattern and both see what it's doing under the hood (vs. being in the code somewhere) and also modify it for their own needs if they'd like to. Anyway, just a thought. On Sat, Sep 20, 2014 at 8:13 PM, George Joseph george.jos...@fairview5.com wrote: On Sat, Sep 20, 2014 at 4:44 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip How about we use the pattern approach but compile in patterns for trunk and user. There are lots of minor differences between ITSPs and phones and I just worry that in the quest to create something for everyone we create something that's useful to no one. If it does not impact any of the existing code and is easy for a user, then sure. That being said... get feedback any way you can before doing anything. This is a complicated area. Unfortunately, it looks like everyone took Saturday off. What gives? :) -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sun, Sep 21, 2014 at 11:07 AM, Brad Watkins marqui...@gmail.com wrote: I'm just throwing this out there, but what if the pattern (we'll use that name for now, although I'm not sure I like it as the final name) could itself define new types. Then, if you provided a standard config (i.e., the sample config) which defined some set of standard types (phone, itsp/trunk, whatever) you could have configurations with semantics similar to what Josh originally proposed. It also means a user of Asterisk can look at the config for the pattern and both see what it's doing under the hood (vs. being in the code somewhere) and also modify it for their own needs if they'd like to. Anyway, just a thought. Makes sense to me. -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
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. 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. 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. 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. I look forward to seeing what others think! 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: snip 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. As base objects it's a bad idea. As a single object to rule them all (a user) it's also a complicated/bad idea. As higher level concepts which represent things that people are familiar with they're fine. -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip 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. As base objects it's a bad idea. As a single object to rule them all (a user) it's also a complicated/bad idea. As higher level concepts which represent things that people are familiar with they're fine. Since endpoint really contains most of the detailed config parameters, would you see enhancements to endpoint that allow direct specification of simple things like username, password, contact, etc. or really a separate object like trunk, user, etc.? I'm guessing the latter but the former would be a lot easier to implement. -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 12:06 PM, George Joseph george.jos...@fairview5.com wrote: On Sat, Sep 20, 2014 at 11:21 AM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip 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. As base objects it's a bad idea. As a single object to rule them all (a user) it's also a complicated/bad idea. As higher level concepts which represent things that people are familiar with they're fine. Since endpoint really contains most of the detailed config parameters, would you see enhancements to endpoint that allow direct specification of simple things like username, password, contact, etc. or really a separate object like trunk, user, etc.? I'm guessing the latter but the former would be a lot easier to implement. Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: snip Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing the two defeats the purpose of having a clear boundary. -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing the two defeats the purpose of having a clear boundary. Ok, how about this... 2 new object types called composite and pattern (or whatever) implemented in a separate res_pjsip_* module [mytrunk] type = composite pattern = trunk etc... [trunk] type = pattern register = yes contacts = static outbound_auth = yes inbound_auth = no identify = yes -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com mailto:jc...@digium.com wrote: George Joseph wrote: snip Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing the two defeats the purpose of having a clear boundary. Ok, how about this... 2 new object types called composite and pattern (or whatever) implemented in a separate res_pjsip_* module [mytrunk] type = composite pattern = trunk etc... [trunk] type = pattern register = yes contacts = static outbound_auth = yes inbound_auth = no identify = yes I don't understand the naming or what they mean at first glance ^_^ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 1:35 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp jc...@digium.com mailto:jc...@digium.com wrote: George Joseph wrote: snip Or separate objects from a config file perspective but implemented in pjsip_configuration with endpoint. Completely separate. Mixing the two defeats the purpose of having a clear boundary. Ok, how about this... 2 new object types called composite and pattern (or whatever) implemented in a separate res_pjsip_* module [mytrunk] type = composite pattern = trunk etc... [trunk] type = pattern register = yes contacts = static outbound_auth = yes inbound_auth = no identify = yes I don't understand the naming or what they mean at first glance ^_^ I was thinking that we probably don't want to create hard coded objects called trunk, user, etc. Instead let the user define the patterns that suit them. So, define a pattern first... [trunk-pattern] type = pattern contacts = static ; would cause a contact line to appear in the aor ; for each server register = yes ; would cause a registration object to be created for each ; server outbound_auth = yes ; would cause an auth object to be created which the ; endpoint would reference as outbound_auth inbound_auth = no ; would do the same thing for endpoint/auth identify = yes ; would cause an identify object to be created with a ; match for each server Actually, the pattern could specify how to construct other variables... client_uri = sip:%OU@%S contact = sip:%S server_uri = sip:%S Now for each trunk... [mytrunk] type = composite pattern = trunk-pattern server = sip1.itsp.com server = sip2.itsp.com outbound_username = myusername outbound_password = mypassword would be the equivalent of... [mytrunk] type = endpoint aors = mytrunk outbound_auth = mytrunk-auth [mytrunk] type = aor contact = sip:sip1.itsp.com contact = sip:sip2.itsp.com [mytrunk-auth] type = auth username = myusername password = mypassword [mytrunk-id] type = identify endpoint = mytrunk match = sip1.itsp.com match = sip2.itsp.com [myrunk-reg-1] type = registration endpoint = mytrunk client_uri = sip:myusern...@sip1.itsp.com server_uri = sip:sip1.itsp.com [myrunk-reg-2] type = registration endpoint = mytrunk client_uri = sip:myusern...@sip2.itsp.com server_uri = sip:sip2.itsp.com -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: snip I was thinking that we probably don't want to create hard coded objects called trunk, user, etc. Instead let the user define the patterns that suit them. It would be much more approachable for a user with specific types. These types result in underlying endpoint, identify, outbound registrations, etc existing but that fact is an underlying detail they don't worry or care about. -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip I was thinking that we probably don't want to create hard coded objects called trunk, user, etc. Instead let the user define the patterns that suit them. It would be much more approachable for a user with specific types. Is this agreement on letting the user define the patterns (with samples provides) or are you saying we should hardcode types? There are enough variations in the patterns that I don't think we could create viable 'trunk', 'user', etc. objects. I'd make this a separate config (pjsip_express.conf or something) with a default set of pattern definitions. These types result in underlying endpoint, identify, outbound registrations, etc existing but that fact is an underlying detail they don't worry or care about. Exactly. -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com mailto:jc...@digium.com wrote: George Joseph wrote: snip I was thinking that we probably don't want to create hard coded objects called trunk, user, etc. Instead let the user define the patterns that suit them. It would be much more approachable for a user with specific types. Is this agreement on letting the user define the patterns (with samples provides) or are you saying we should hardcode types? There are enough variations in the patterns that I don't think we could create viable 'trunk', 'user', etc. objects. I'd make this a separate config (pjsip_express.conf or something) with a default set of pattern definitions. I'm saying for making it easier to configure PJSIP for users there could be hardcoded types which represent the common types that users need. If more control is required than the lower level detailed ones can be used. It is certainly possible to have 'phone' and 'trunk' types which are useful for a good percentage. Your pattern idea I would say is an alternative way for doing it, but is still more complicated than distinct types and requires explanation. Given the following (even without documentation) could someone coming from sip.conf understand it? [1000] type=phone secret=notverysecret context=trusted disallow=all allow=g722 mailbox=1000 I err on the side of yes. That's what I think is needed. Heck, it's hard enough to get people to realize they can use templates. -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 3:13 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: On Sat, Sep 20, 2014 at 2:20 PM, Joshua Colp jc...@digium.com mailto:jc...@digium.com wrote: George Joseph wrote: snip I was thinking that we probably don't want to create hard coded objects called trunk, user, etc. Instead let the user define the patterns that suit them. It would be much more approachable for a user with specific types. Is this agreement on letting the user define the patterns (with samples provides) or are you saying we should hardcode types? There are enough variations in the patterns that I don't think we could create viable 'trunk', 'user', etc. objects. I'd make this a separate config (pjsip_express.conf or something) with a default set of pattern definitions. I'm saying for making it easier to configure PJSIP for users there could be hardcoded types which represent the common types that users need. If more control is required than the lower level detailed ones can be used. It is certainly possible to have 'phone' and 'trunk' types which are useful for a good percentage. Your pattern idea I would say is an alternative way for doing it, but is still more complicated than distinct types and requires explanation. How about we use the pattern approach but compile in patterns for trunk and user. There are lots of minor differences between ITSPs and phones and I just worry that in the quest to create something for everyone we create something that's useful to no one. Given the following (even without documentation) could someone coming from sip.conf understand it? [1000] type=phone secret=notverysecret context=trusted disallow=all allow=g722 mailbox=1000 I err on the side of yes. That's what I think is needed. Heck, it's hard enough to get people to realize they can use templates. I love templates so much that I enhanced manager and config so you read and write templates via AMI GetConfig and UpdateConfig. If we compile in basic patterns it could be as simple as [1000] type = composite ; ok, maybe composite and pattern aren't good names. pattern = phone ; built-in pattern incoming_password = notverysecret context = trusted disallow = all allow = g722 mailboxes = 1000 Are you OK with a separate config file? It would make manipulating it easier since there'd be no duplicate section names. -- _ -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
George Joseph wrote: snip How about we use the pattern approach but compile in patterns for trunk and user. There are lots of minor differences between ITSPs and phones and I just worry that in the quest to create something for everyone we create something that's useful to no one. If it does not impact any of the existing code and is easy for a user, then sure. That being said... get feedback any way you can before doing anything. This is a complicated area. Given the following (even without documentation) could someone coming from sip.conf understand it? [1000] type=phone secret=notverysecret context=trusted disallow=all allow=g722 mailbox=1000 I err on the side of yes. That's what I think is needed. Heck, it's hard enough to get people to realize they can use templates. I love templates so much that I enhanced manager and config so you read and write templates via AMI GetConfig and UpdateConfig. If we compile in basic patterns it could be as simple as [1000] type = composite ; ok, maybe composite and pattern aren't good names. pattern = phone ; built-in pattern incoming_password = notverysecret context = trusted disallow = all allow = g722 mailboxes = 1000 Are you OK with a separate config file? It would make manipulating it easier since there'd be no duplicate section names. Yes. -- 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
Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
On Sat, Sep 20, 2014 at 4:44 PM, Joshua Colp jc...@digium.com wrote: George Joseph wrote: snip How about we use the pattern approach but compile in patterns for trunk and user. There are lots of minor differences between ITSPs and phones and I just worry that in the quest to create something for everyone we create something that's useful to no one. If it does not impact any of the existing code and is easy for a user, then sure. That being said... get feedback any way you can before doing anything. This is a complicated area. Unfortunately, it looks like everyone took Saturday off. What gives? :) -- _ -- 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
[asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
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
