I have seen a UA implementation that changes the case of the branch tag to ALL CAPS when responding to incoming requests (i.e., even if the request is mixed case, the response is always all caps). How does this play into branch equality, given the requirement of RFC 3261 section 8.2.6.2?
8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. Are two branches equal if they match case insensitively? Patrick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Procter Sent: Wednesday, March 15, 2006 4:14 AM To: Vijay K. Gurbani Cc: Sip-Implementors Subject: Re: [Sip-implementors] Is the "magic cookie" inthe Viabranch case-sensitive? > FWIW, I agree with Dale. I think the intent is case sensitive for the > very reasons that Dale mentioned. Maybe we are talking at cross purposes here. The intent of the magic cookie inventor seems likely to be for the comparison to be case sensitive - otherwise why bother with the mixed case cookie. The intent of RFC3261 is for the comparison to be case insensitive - see RFC3261 section 7.3.1. 'When comparing header fields...'. So, which intent do we honour? I think we should follow the RFC. I think the purpose of Bug 661 is to highlight the ambiguity, but I can see that the text in the bug description isn't completely unambiguous! > Actually, I am not quite sure how to interpret the textual description > in the bugs database. I interpret it to mean that what is called out > in the spec is the need to ensure that the branch id *following* the > magic cookie be compared case insensitive (which is fine by me). I'm not sure that that is the most natural reading. I interpret it as saying that the entire tag should be compared insensitively despite the apparent case sensitivity of the cookie. But to be honest, I don't think it really matters, if the following rules apply to the UAC: 1) Never permute the case of branch IDs between retransmissions. 2) Always generate branch IDs that differ by more than just the case of some letters. The first rule is likely to be followed by everything, whether they realise it or not. The second rule won't cause many problems even if it is broken - the chance of two branch IDs being generated that only differ by the case of some letters, and that both are used within 32 seconds on the same dialog, seem small at best[1]. So, to conclude, I think the 'magic cookie' should be compared case insensitively. But if you want to compare it sensitively, I don't think bad things will happen very often, if ever. Regards, Michael Procter [1] Yes, you could arrange a generator to violate this more frequently, but if you are aware of the problem, you are more likely to avoid it rather than try to cause it. I hope. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
