[asterisk-dev] PJSip Identify idea

[Steve Murphy]

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




-- 

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/20151021/2df77109/attachment.html>