[Kamailio-Devel] compare uri and aor

[Daniel-Constantin Mierla]

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 at domain
> b)  sip:alice at 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 at domain;custom_param=AAA
> b)  sip:alice at domain;custom_param=BBB
> The are different since they share a URI parameter with different value.
>
> a)  sip:alice at domain;custom_param_1=AAA
> b)  sip:alice at 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 at domain" differs from
> "sip:alice at 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 at 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 at 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