Michael-- Sorry for the lapse, I've been pretty busy, but have broken away to look at this a little closer.
On Wed, Oct 21, 2015 at 12:51 PM, Michael Ulitskiy <[email protected]> wrote: > Hi Steve, > > > > In my opinion, while your idea sounds cool and dandy, going for a > low-hanging fruit > > and making it possible to select endpoint match order (ip or from > username) per-endpoint, > > would go a long way to improve current system and I'd have use case for it > right now. > > > > 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! 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. So, my idea applies to where the line=yes and the match= don't quite cut it. murf > > Thanks, > > Michael > > > -- Steve Murphy ParseTree Corporation 57 Lane 17 Cody, WY 82414 ✉ murf at parsetree dot com ☎ 307-899-5535
-- _____________________________________________________________________ -- 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
