" Think about this from the perspective of a UAS - if two UACs start talking to it at once and happen to use the same branch parameter value, the results will be incorrect matching of message to transaction."
This is what we have experienced and hence I had asked this question. Atleast from the RFC it was not clear to me that the "branch value MUST be unique for all request sent by different UA". As Brett pointed out the, stack could have avoided this situation by checking for sent by and the branch value for the transaction to message matching but I do see that this is not followed by stack. Regards -venkat -----Original Message----- From: Robert Sparks [mailto:[email protected]] Sent: Friday, February 06, 2009 8:51 PM To: Dale Worley Cc: VYANKTESH TADKOD; [email protected]; Brett Tate Subject: Re: [Sip-implementors] Question on Branch parameter usage So I think we're identifying there is ambiguity in the sentence "The branch parameter value MUST be unique across space and time for all requests sent by the UA. " on page 39 of RFC 3261. It was intended, and is necessary for correct operation, that this parameter be unique across space and time. Think about this from the perspective of a UAS - if two UACs start talking to it at once and happen to use the same branch parameter value, the results will be incorrect matching of message to transaction. Unless someone objects, I'll create a bug to track this for clarification. RjS On Feb 5, 2009, at 5:07 PM, Dale Worley wrote: > On Wed, 2009-02-04 at 14:04 +0100, VYANKTESH TADKOD wrote: >> But in any case is it >> acceptable to have 2 UAs generating the same branch value? As per >> RFC I >> think the answer is "NO" but it is not very clear. > > As Brett noted, RFC 3261 seems to allow the branch to be only unique > among all requests generated by a UA. But the accepted practice is > that > it must be unique over all space and time. (Since the UA must be able > to generate Call-IDs that are unique over all space and time, it can > also generate branch parameters that are, so there is no additional > burden on the UA.) > > Dale > > > _______________________________________________ > 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
