On 01/07/2009 12:47 PM, Iñaki Baz Castillo wrote: > [...] >> Now, for URI it does comparison of: >> - username >> - password >> - hostname >> - port >> > > Are URI parameters taken into account?: > Not now, it is why I started the debate, to figure out where to stop this matching. Then I will announce the new feature. > 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? > Fully agree. I haven't seen URIs with headers, but they might be somewhere inside IMS/Telco routing...
> > >> - 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 > Annoying, but possible. > 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 will leave the port matching for AoR then. If someone complains, we will figure out then. For URI, probably I should add the checks for URI parameters and then stop there. Any other opinion? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com _______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
