An early dialog is only established by a 1xx response with a to-tag. A CANCEL can be sent as along as any 1xx response has been received. Typically, a 100-Trying will be received from the next hop proxy. This 100-Trying will not usually have a to-tag since it is generated by a proxy and not a UAS.
The CANCEL applies to all branches of the INVITE. If any proxy along the path forked the INVITE toward multiple User Agents, there will be multiple branches and possibly multiple early dialogs depending on how many UAS's sent back a 1xx with a to-tag. You use CANCEL to terminate the INVITE transaction and all branches and early dialogs it created. That is why the CANCEL must match the INVITE exactly. You use BYE if you wish to terminate a specific early dialog, but let any other branches or early dialogs complete. In the case of a re-INVITE on an existing confirmed dialog, the INVITE will not be forked and will reach the other UA in the dialog. A CANCEL could be used to cancel the re-INVITE without terminating the dialog. However, this may not be very useful since most UAs will send back a final response to the re-INVITE fairly quickly and the CANCEL would not reach the UA in time. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] ----- Original Message ----- From: "vimal srivastava" <[EMAIL PROTECTED]> >I am not sure I understood. following lines > With an initial INVITE, you cannot send CANCEL for an early dialog by > including the to-tag from a 1xx response. > > If you wish to cancel/terminate a specific early dialog, you use BYE. See > section 15 of RFC 3261 for details. > > > 3261 Page 70 says > A dialog can also be in the "early" > state, which occurs when it is created with a provisional response, > and then transition to the "confirmed" state when a 2xx final > response arrives. > vimal: so by early dialog i understand, only provisional response is > received. > > > 3261 page 54 > If no provisional response has been received, the CANCEL request MUST > NOT be sent; rather, the client MUST wait for the arrival of a > provisional response before sending the request. If the original > request has generated a final response, the CANCEL SHOULD NOT be > sent, as it is an effective no-op, since CANCEL has no effect on > requests that have already generated a final response. > vimal: this means that cancel can be sent only for early dialog. if final > response is already received no point sending cancel. > > From: "Bob Penfield" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>,"'Nataraju A B'" > <[EMAIL PROTECTED]>,"'Banibrata Dutta'" > <[EMAIL PROTECTED]>,"'Sip-Implementors (E-mail)'" > <[email protected]> > Subject: Re: [Sip-implementors] CANCEL request in the INVITE initiated > Dialog > Date: Thu, 15 Dec 2005 14:06:04 -0500 > > The CANCEL MUST have the same to-tag as the INVITE it is cancelling. > > If the INVITE had a to-tag, the CANCEL MUST have the same to-tag. > > If the INVITE did not have a to-tag, the CANCEL MUST NOT have a to-tag. > > Section 9.1 of RFC 3261 is very clear on this: > > The Request-URI, Call-ID, To, the numeric part of CSeq, and > From header fields in the CANCEL request MUST be identical to > those in the request being cancelled, including tags. > > With an initial INVITE, you cannot send CANCEL for an early dialog by > including the to-tag from a 1xx response. > > If you wish to cancel/terminate a specific early dialog, you use BYE. See > section 15 of RFC 3261 for details. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > [EMAIL PROTECTED] > > > > > ----- Original Message ----- > From: "Manjunath Warad" <[EMAIL PROTECTED]> > To: "'Nataraju A B'" <[EMAIL PROTECTED]>; "'Banibrata Dutta'" > <[EMAIL PROTECTED]>; "'Sip-Implementors (E-mail)'" > <[email protected]> > Sent: Thursday, December 15, 2005 6:24 AM > Subject: Re: [Sip-implementors] CANCEL request in the INVITE initiated > Dialog > > > > Hi > > One more reason why To tag is optional in Cancel, since Cancel will > > be matched with the transaction of INVITE and for the transaction match > To > > tag is not required, rather it matches with Branch-Id. Branch-Id being > > unique will identify which INVITE it is cancelling. > > > > Regards, > > Manju > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju > > A > > B > > Sent: Thursday, December 15, 2005 4:39 PM > > To: 'Banibrata Dutta'; 'Sip-Implementors (E-mail)' > > Subject: Re: [Sip-implementors] CANCEL request in the INVITE initiated > > Dialog > > > > > > > > > > Thanks & Regards, > > Nataraju A.B. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Banibrata > > Dutta > > Sent: Thursday, December 15, 2005 3:02 PM > > To: Sip-Implementors (E-mail) > > Subject: [Sip-implementors] CANCEL request in the INVITE initiated > > Dialog > > > > hi, > > > > a CANCEL sent for an INVITE will in the INVITE initiated Dialog. So > should > > the CANCEL request have both the From & To tags, or just the From tag ? > > I > > believe that both should be sent, because the full Dialog related > > information could be available from the received provisional response > > (s.a. > > 182 or 183). > > > > > > [ABN] the CANCEL request may optionally contain the to-tag. Since 100 > > Trying > > response may not carry the to-tag. If some 1xx response received which > > carried to-tag, this tag might be put in CANCEL request, but none of the > > intermediate entities or servers mandate the presence of to-tag in > > CANCEL > > request processing...... > > > > thanks for any clarification. > > > > regards, > > bdutta > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
