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>
-- _____________________________________________________________________ -- 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
