[asterisk-dev] PJSip Identify idea

Wed Oct 28 17:22:19 CDT 2015

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 <mulitskiy at acedsl.com>
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 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
>
> --
> _____________________________________________________________________
> -- 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151028/5a00265c/attachment.html>