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&gr...
Now, for URI it does comparison of: - username - password - hostname - port
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? - 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?
Cheers, Daniel
2009/1/7 Daniel-Constantin Mierla miconda@gmail.com:
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&gr...
Great :)
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.
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).
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: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.
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: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
Annoying, but possible.
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
2009/1/8 Daniel-Constantin Mierla miconda@gmail.com:
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...
I've seen some URI's containing headers in some hyper-xtra-exotic drafts that will be NEVER implemented, of course. They are things like a server receiving a request with a special body full of URI's containing headers. So the server creates a request for each URI and adds the URI headers as request headers.
This pathetic feature (written by somebody obviously not interested in its implementation but in writting a paper in which his name appears) would be never a task for a proxy but for a exotic server.
I think a proxy should never care about useless URI headers.
Regards.
On 01/08/2009 02:48 PM, Iñaki Baz Castillo wrote:
2009/1/8 Daniel-Constantin Mierla miconda@gmail.com:
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...
I've seen some URI's containing headers in some hyper-xtra-exotic drafts that will be NEVER implemented, of course. They are things like a server receiving a request with a special body full of URI's containing headers. So the server creates a request for each URI and adds the URI headers as request headers.
This pathetic feature (written by somebody obviously not interested in its implementation but in writting a paper in which his name appears) would be never a task for a proxy but for a exotic server.
:-) -- I guess it has created a good market for SIP conformance testing tools...
Cheers, Daniel
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com