For some implementations yes, they should be treated as the same branch. I think it depends on the entity that developed the software. The RFC is not explicit enough.
Jose Simoes On 3/18/06, Patrick Timmons <[EMAIL PROTECTED]> wrote: > > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
