[asterisk-dev] PJSip Identify idea

Michael Ulitskiy mulitskiy at acedsl.com
Wed Oct 28 16:36:38 CDT 2015


> > 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 at my_provider.com
> From: <who_cares>
> To: <who_cares>
> Contact: <sip:my_contact_uri at my_pbx.com;line=ds824hds>
> <sip:my_contact_uri at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151028/73413558/attachment-0001.html>


More information about the asterisk-dev mailing list