Hi, We will log a bug in bugzilla about this. We will clarify this behaviour in future versions of the spec.
Thanks, Gonzalo Arunachalam Venkatraman wrote: > > Christer/Gonzalo > Thanks to Christer for your explanation of the algorithm for generating a To > tag. > It does, however, conflict with the RFC2361 statements in 19.3 - > > When a tag is generated by a UA for insertion into a request or > response, it MUST be globally unique and cryptographically random > with at least 32 bits of randomness. > > Besides the requirement for global uniqueness, the algorithm for > generating a tag is implementation-specific. Tags are helpful in > > These statements do not suggest that the tag is to be a hash of request > parameters. Several implementations simply add a 32 bit random quantity as > the TO tag. > > ???? > > Venkat > > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 16, 2002 9:25 AM > To: Arunachalam Venkatraman > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] rfc3261 - Stateless UAS > > Hi, > > > In 8.2.7 Stateless UAS Behavior > > > > o A stateless UAS MUST ignore CANCEL requests. > > > > o To header tags MUST be generated for responses in a stateless > > manner - in a manner that will generate the same tag for the > > same request consistently. For information on tag construction > > see Section 19.3. > > > > Questions: > > 1. Why should a stateless UAS ignore CANCEL? I would expect it to respond > > with a 481he CANCEL. > > > > 2. Why does a a stateless UAS need to generate the same TO tag? If the > > request retransmits and the response has a different tag, it will only > > appear (to the uac) to have forked. > > Since the tag is just a gloablly random quantity and is not a hash of the > > request parameters, it will not be the same. > > I asked about this myself a while ago, because I thought it was a little > confusing. > > However, I got a clarification from Gonzalo Camarillo (to make sure I > understood him correctly I CC this mail to him, so he can correct me if > what > I'm saying now is wrong :). > > What he said was that you do need to calculate a hash to get the To tag, and > part of the input to that hash has to be a random number. That random > number, > however, does not need to be random in the sense that it's unique every time > you generate it. It shall be unique for your NODE, however, but you can use > the same number every time you calculate the hash. You then have to choose > the headers you use as input for the hash so that the result is different > for > each new INVITE, but the random number you use will be the same every time. > So, in the case of request re-transmits, since you will use the same > headers, > and the same random number, for the hash calculation for each re-transmit of > the request, you will get the same result every time. > > Regards, > > Christer Holmberg > Ericsson Finland -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : [EMAIL PROTECTED] Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
