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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
