[asterisk-dev] PJSip Identify idea

[Michael Ulitskiy]

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.

Thanks,
Michael

On Wednesday, October 21, 2015 11:29:45 AM Steve Murphy wrote:
> I recently had a discussion with Mark about assigning an incoming
> request to a particular endpoint. He wrote:
> 
> If your problem has nothing to do with outbound registrations, then
> something more like what you described would need to be devised. However, I
> would prefer that if new development were being discussed that such a thing
> be moved to the asterisk-dev mailing list. Some things to keep in mind here
> are:
>  * It's a bit difficult at the moment to try to match an endpoint based on
> multiple criteria with the way identification modules work. If one module
> says they recognize the endpoint, that's enough for a match right now.
> 
> Don't we specify the order of evaluation?
> And, can't we probably override this order by using
> the identify_by=<whatever> inside an endpoint?
> 
>  * Modifying res_pjsip_endpoint_identifier_ip.c to match on other criteria
> may make sense, but then what happens if someone wants to match based on
> multiple criteria based on some other "base" for identification (e.g. what
> if someone wants to make a match based on From header and Contact header
> but they don't care about the originating IP address) ?
> 
> Let me say that based on some recent developments and discussions, I think
> the methods for identifying endpoints in res_pjsip* modules could use
> improvement, but I don't think it's necessarily going to be an easy thing
> to just add to what's there. I may be wrong about that, but every time I
> start to think about it too hard, my head starts hurting.
> 
> I've been playing with res_pjsip_endpoint_identifier_ip.c,
> and I see it as a great placeholder to hold a much more general
> matching mechanism.
> 
> Observation:
> 
> Rght now, you have a single "match" line with a list of ip's. If any of
> those
> IP's match, it's a success, and you assign the endpoint specified. That's
> an OR operation...
> 
> Idea:
> 
> Several different "match" types. Each type has to have at least one
> "match" for the that match to be a success.
> All the matches have to be successful, before the endpoint
> is considered to be selection.
> 
> Thus, it ends up being the AND of match types, and each match is an OR
> among possibilities. It's not as general as a fancy expression with tons of
> possible variables (a selection language with logical operators, and
> whatnot),
> but it should be easy to implement and fairly useful.
> 
> That leaves match types:
> 
> match   -- the current, with a list of IP's, or ip/mask or ip/cidr
> 
> match_<header name>_<field name>  -- a set of possible matches: regex's
> (with
> no embedded commas, or some quoting mech to wrap around regex's).
> 
> header names would be to, from, contact, remote-party-id,
> and any other reasonably possible headers.
> 
> Field name would be username, host, port, and any other appropriate fields,
> and these would be a function of the kind of header, and what might be
> found in it.
> 
> match_to_username=john,.*-ann,betty,sue,z.*
> match_from_username=fred,alice,bob,.120210112[0-9][0-9]
> match_contact_host=3.3.4.0/24,somedomain.biz
> match_remote-party-id_username=Campbell
> 
> and so on.
> 
> I think this new module could replace the current
> res_endpoint_identifier_ip module,
> as it would provide its functionality and add a chunk more, and
> not change existing usage or contents.
> 
> 
> Does this sound useful to anyone?
> 
> murf
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151021/c64c6232/attachment-0001.html>