[asterisk-dev] PJSip Identify idea

Wed Oct 28 21:27:39 CDT 2015

Steve,

I just realized that my logic is flawed.
You can't have per-endpoint matching order option, because then to know how to match endpoint
you first need to know which endpoint it is and to know that you need to know how to match it...
I feel embarassed.
I guess I need to re-think my approach.
Please forget everything I've said.

Michael

On Wednesday, October 28, 2015 04:22:19 PM Steve Murphy wrote:
> 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
> >
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151028/f23b7f9c/attachment-0001.html>