Michael-- Assuming that the line=yes takes care of all of your trunk providers, and all your phones are handled by the "username" directive, you can play around with the existing "ip" type , and use a different "identify" section for each endpoint to get that one-on-one matching. Especially if the identify sections have the added concepts from my first message!
What kind of use-case are you looking at, anyway? murf On Wed, Oct 28, 2015 at 3:36 PM, Michael Ulitskiy <[email protected]> wrote: > > > Currently endpoint match order is selected for the whole asterisk > server > > > > by the order of loading > > > > > > > > res_pjsip_endpoint_identifier_* modules and that leaves much to be > desired. > > > > > > > > > > > > > This is interesting. I'm looking at the 13.5 code, and I see, in > > > res_pjsip.c, the function: > ast_sip_register_endpoint_identifier_with_name(). > > > It is called as part of the load_module() process for each identify > module. > > > > > > That function calls ast_sip_get_endpoint_identifier_order, which appears > to > > > return the string from the pjsip.conf file, > > > in the [global] section, the variable "endpoint_identifier_order" > (default > > > in the sample file is: ip, username, anonymous). > > > > > > It sets a priority that the code should respect, and force the list to be > > > in that order, no matter what the > > > load order is. > > > > > > I also note that if you don't define that variable in the config file, > the > > > code just throws the modules into the list at the end, > > > which would sort them in order of loading. This seems to me a bug-- the > > > sample file says there's a default, but > > > the code says otherwise. > > > > > > So, if you wish to set the global order, you should define the > > > "endpoint_identifier_order" variable. And if it still > > > sorts by load order, then there's another bug to be fixed! > > > > I haven't read the actual code. This information from asterisk wiki: > > > https://wiki.asterisk.org/wiki/display/AST/Endpoints+and+Location,+A+Match+Made+in+Heaven > > > > Quoting: "The load order of the endpoint identifiers determines the order > in which they are called for endpoint identification purposes" > > > > Basically the same information is present here: > > > https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships > > > > Quoting: "If you don't have an identify section defined, or else you have > res_pjsip_endpoint_identifier_ip loading after res_pjsip_endpoint_ > identifier_user, > > then res_pjsip_endpoint_identifier_user will identify inbound traffic by > pulling the user from the "From:" SIP header in the packet. Basically the > module load > > order, and your configuration will both determine whether you identify by > IP or by user." > > > > I did see "endpoint_identifier_order" option and while I didn't tested it > thoroughly, I remember trying to quickly play with it and it didn't work. > > > > Either way it's still global option and doesn't help things much. I'd like > to have an option configurable per-endpoint. > > > > > The function "ast_sip_identify_endpoint(rxdata)" is the function that > gets > > > called to actually find the endpoint for > > > the incoming sip message. It runs thru the endpoint_identifier_list as > set > > > up by the above _register func, and therefore, > > > the code should obey that order. > > > > > > Mark Michelson also explained how the line=yes directive works in > outbound > > > registrations, as you would > > > expect from trunk providers, and that mechanism should work no matter > what > > > the endpoint_identifier_order was > > > set to be. I personally think this is a really cool way to tie incoming > > > INVITES to the correct endpoint, when > > > several endpoints might otherwise qualify. > > > > > > Here is a snippet from an email I got from Mark: > > > > > > Question 1: Where should the ;line=xxxxx field be included in the > incoming > > > invite, so that Asterisk can properly use it to select the correct > endpoint? > > > (my personal guess: on the Contact: header ?) > > > > > > > > > Here's a bigger breakdown of how this works. Asterisk sends a REGISTER > that > > > looks something like: > > > REGISTER sip:my_provider@my_provider.com > > > From: <who_cares> > > > To: <who_cares> > > > Contact: <sip:my_contact_uri@my_pbx.com;line=ds824hds> > > > <sip:my_contact_uri@my_pbx.com;line=ds824hds>;expires=3600 > > > > > > So now, when the provider sends an INVITE to Asterisk, it should send > > > INVITEs to sip:my_contact_uri@my_pbx.com;line=ds824hds. That URI should > be > > > in either or both of the request-URI (i.e. the top line of the SIP > packet) > > > or the To header. > > > ... > > > ... The trick here is that the line parameter is a URI parameter, rather > > > than a parameter on the Contact header itself. The rule that the provider > > > is following states that it needs to route the call to the URI that is > > > bound to a particular AOR. If we bind a URI with a line parameter, then > > > that line parameter had better show up in requests to us from the > provider. > > > > > > A little research shows that whoever you register to should regurgitate > the > > > URI you send in the contact header. > > > And if "line=yes" is present, Asterisk will insert that "line=xxxxx" > field > > > in the contact URI, and when invites > > > arrives with the URI having that "line=xxxxx", it will match that to the > > > correct specified endpoint. > > > > This is actually interesting. I didn't see/notice it. > > Good to know. Thanks! > > > > > So, my idea applies to where the line=yes and the match= don't quite cut > it. > > > > > > murf > > > > Michael > > -- > _____________________________________________________________________ > -- 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 > -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-5535 *The Beginning of the End:* Civil Forfeiture: Police turn from Protectors to Predators <https://www.youtube.com/watch?v=3kEpZWGgJks> Corporate Vigilantism & Use of Psychological Torture <http://2tellthewholetruth.blogspot.com/?view=classic>
-- _____________________________________________________________________ -- 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
