[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