100 trying is also a provisional response. Provisional responses will not always create an early dialog (not necessary to have a To Tag).
The reason you need to wait for a provisional response before sending the cancel is to make sure you are not in the re-transmitting mode of the INVITE request while sending cancel. Otherwise it is possible that the UAS/Proxies may receive the cancel before the retransmitted Invite (Assuming the first few Invites or lost). In these cases the cancel will result in 481 and UAC may still get a 200 OK or other provisional responses for the INVITES. Regards Kasturi -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vimal srivastava Sent: Monday, December 19, 2005 10:19 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] CANCEL request in the INVITE initiated Dialog 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
