Its for in-dialog request fro mthe reverse side.. because for reverse side, from tag will be local tag which it had generated so if it is RFC 3261 compliant, it will not be null..
hence from tag will be non-null and to-tag will be null.. udit gupta gaurav <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/27/2005 06:46 AM To "Dale R. Worley" <[EMAIL PROTECTED]>, Sip-Implementors <[email protected]> cc Subject Re: [Sip-implementors] Re: [Sip] IN VITE with different from tag 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 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
