On Wed, 2005-10-26 at 10:34 -0500, Dennis Dupont wrote: > Can you please elaborate on why this is forbidden (RFC reference?). I > was under the impression that as part of the dialog-defining set of > headers that this was perfectly legal. Otherwise, if the Call-Id > defines uniqueness, what is the point in 3261 defining a dialog at all?
8.1.1 Generating the Request 8.1.1.3 From The From field MUST contain a new "tag" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag. 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. [...] In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. 19.3 Tags 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. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for "hairpinning" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags. Every dialog-starting request must have a unique Call-ID. It also has to have a unique from-tag. Every successful response to the request has to have a unique to-tag. Since there can be multiple early dialogs generated by one request, the to-tag has to be part of the dialog identification. In theory the from-tag could be omitted, since it is determined by the Call-ID, but for symmetry's sake it is not. (If the initial from-tag was omitted, an in-dialog request going in the reverse direction would have a from-tag but not a to-tag.) Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
