[asterisk-dev] PJSip Identify idea

[Steve Murphy]

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 <mulitskiy at acedsl.com>
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 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151028/481c1d86/attachment.html>