Re: [Sip-implementors] Contact header URI comaprision

[Dale R. Worley]

Paul Kyzivat  writes:
>> Contact: "" 
>> 
>> Contact: "" 
>> 
>
> What leads you to this conclusion? Parameter order is never relevant.

Specifically, a little earlier in section 19.1.4 is:

  o  The ordering of parameters and header fields is not significant
 in comparing SIP and SIPS URIs.

>> I am facing an issue on which the contact URI comparison has happened and
>> it fails due to the TRC parameter not in order which I guess so far.

By the rules of 3261, these two URIs are equivalent.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Contact header URI comaprision

[Paul Kyzivat]

On 7/14/17 3:53 AM, Rakesh wrote:

Hi Expert,

I am facing an issue on which the contact URI comparison has happened 
and it fails due to the TRC parameter not in order which I guess so far.


Contact: "" 

Contact: "" 



I saw in RFC 3261 19.1.4 URI Comparison

URI uri-parameter components are compared as follows:


...

The following:


  -  All other uri-parameters appearing in only one URI are
 ignored when comparing the URIs.


is the operative rule here.

So does it mean the correct order should be given below where the TRC 
parameter should be put at the last?


Contact: "" 

Contact: "" 



What leads you to this conclusion? Parameter order is never relevant.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Contact header URI comaprision

[Rakesh]

Hi Expert,

I am facing an issue on which the contact URI comparison has happened and
it fails due to the TRC parameter not in order which I guess so far.

Contact: "" 
Contact: "" 

I saw in RFC 3261 19.1.4 URI Comparison

URI uri-parameter components are compared as follows:

 -  Any uri-parameter appearing in both URIs must match.

 -  A user, ttl, or method uri-parameter appearing in only one
URI never matches, even if it contains the default value.

 -  A URI that includes an maddr parameter will not match a URI
that contains no maddr parameter.

 -  All other uri-parameters appearing in only one URI are
ignored when comparing the URIs.



Rosenberg, et. al.  Standards Track   [Page 154]


RFC 3261SIP: Session Initiation Protocol   June 2002


   URI header components are never ignored.  Any present header
 component MUST be present in both URIs and match for the URIs
 to match.  The matching rules are defined for each header field
 in Section 20.


And


Note that equality is not transitive:

  sip:ca...@chicago.com and sip:ca...@chicago.com;security=on are
 equivalent

  sip:ca...@chicago.com and sip:ca...@chicago.com;security=off
 are equivalent




Rosenberg, et. al.  Standards Track   [Page 155]


RFC 3261SIP: Session Initiation Protocol   June 2002


 sip:ca...@chicago.com;security=on and
 sip:ca...@chicago.com;security=off are not equivalent

So does it mean the correct order should be given below where the TRC
parameter should be put at the last?

Contact: "" 
Contact: "" 

BR///

Rakesh Kumar Mohanty
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors