8 Jan
2009
8 Jan
'09
7:11 a.m.
On 01/07/2009 12:47 PM, Iñaki Baz Castillo wrote:
Annoying, but possible.
[...]
Not now, it is why I started the debate, to figure out where to stop
this matching. Then I will announce the new feature.
Now, for URI it does comparison of:
- username
- password
- hostname
- port
Are URI parameters taken into account?:
a) sip:alice@domain
b) sip:alice@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:alice@domain;custom_param=AAA
b) sip:alice@domain;custom_param=BBB
The are different since they share a URI parameter with different value.
a) sip:alice@domain;custom_param_1=AAA
b) sip:alice@domain;custom_param_2=BBB
They match since custom parameters are just matched when they exist in
both URI's.
Fully agree. I haven't seen URIs with headers, but they might be
somewhere inside IMS/Telco routing...
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:alice@domain" differs from
"sip:alice@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:alice@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:alice@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