Hi Dale I am a bit confused on the last statement which says "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.)"
As far as I know, the from-tag in initial request can be missed only by a 2543 compliant UA since it is mandatory for a 3261 compliant UA. So by this do u mean to say that if a 3261 compliant UA receives a request having no From-tag, it will generate a response to that request having a To-tag but no From-tag & subsequent requests from 3261 UA will contain a From-tag ( same as To-tag generated in first response) but no To-tag ? Regards Gaurav --- "Dale R. Worley" <[EMAIL PROTECTED]> wrote: > 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 > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
