2009/1/7 Daniel-Constantin Mierla <[email protected]>: > Hello, > > I have introduced in siputils module functions to compare SIP URI and > AoR in a more RFC manner, related to: > https://sourceforge.net/tracker/index.php?func=detail&aid=2047019&group_id=139143&atid=743023
Great :) > Now, for URI it does comparison of: > - username > - password > - hostname > - port Are URI parameters taken into account?: a) sip:al...@domain b) sip:al...@domain;transport=tcp They are different since a) could involve UDP transport while b) forces TCP. A user, ttl, maddr, or method uri-parameter appearing in only one URI never matches, even if it contains the default value. a) sip:al...@domain;custom_param=AAA b) sip:al...@domain;custom_param=BBB The are different since they share a URI parameter with different value. a) sip:al...@domain;custom_param_1=AAA b) sip:al...@domain;custom_param_2=BBB They match since custom parameters are just matched when they exist in both URI's. > For AoR, it does: > - username > - hostname > - port (if port is missing, it assumes 5060 -- for URI comparison this > is not used, conform to RFC3261) > > The questions are: > - shall the comparison for URI be extended to follow full RFC? could get > complex when taking URI headers in account -- haven't seen many, but the > RFC allow them. Where to stop then the rules for comparing the URI? Personally I would never implement exotic URI headers. This is something that should be dropped from RFC 3261 ASAP. Those super-exotic "features" are fully useless and add extra-complexity. Why should a header be matched when comparing an URI? > - for AoR, I am not sure if port should be considered, but when running > multiple instances on different ports, it may make the difference? What > do you think? Complex question. Probably port must be taken into account since, as you say, the same server (same domain) could have two servers in different ports, so "sip:al...@domain" differs from "sip:al...@domain:5070". But also, it breaks RFC 3263. For example, if a server listens in "domain:5070" and there are no SRV registers for "_sip._udp.domain" pointing to port 5070, then it requires the user configure an account with this data: user: alice domain: domain:5070 <-- annoying So the From would be: From: <sip:al...@domain:5070> If the user configures his device with "domain = domain" (no port) and uses an outbound proxy (domain:5070) then his From would point to a different server (a MESSAGE conversation would fail when a reply MESSAGE goes to "sip:al...@domain"). Unfortunatelly I've already seen some implementations adding the default port 5060 to the From domain even if no port is set in the configuration (just the domain). So in conclussion I think your approach is correct (or the least wrong xD). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Devel mailing list [email protected] http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
