inline. ----- Original Message ----- From: "Thomas Froment" <[EMAIL PROTECTED]>
> Hi, > thanks for your response, > > Bob Penfield wrote: > > >The CANCEL must have the same to-tag as the INVITE, not the 1xx response. > > > I don't understand this point, 1xx response and 2xx response have the > same toTag since they are in the same dialog ... > aren't they ? They will be the same if they are for the same dialog. If a proxy forks an initial INVITE (no to-tag) to multiple UASs, it is possible the UAC will see multiple 1xx responses with different to-tags (for different UASs). The CANCEL must must match the INVITE so that the proxy will fork the CANCEL to the same UASs. > > >The ACK will have the same to-tag as the final response to the INVITE > >(usually 487 for a cancelled INVITE). > > > >RFC 3261, Section 9.1 states: > > 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. > > > >The CANCEL tags match the INVITE tags so that all branches (forks) for the > >INVITE are cancelled. CANCEL is not used to terminate an early dialog. To > >terminate a specific early dialog, BYE is used (see section 15). > > > > but I need to be more precise: > my scenario is the following: > > UAC ------------------> SENDS INVITE (with callid=A, fromTag=B, and no > toTag) ----------------> UAS > UAS ------------------> ANSWER 100 TRYING, then 200 OK (200 ok, with > CallId=A, fromTag=B, and toTag=C) --------------> UAC > at this step, my UAS created a session with dialogID=ABC Once you receive a final response (200-OK), you can no longer CANCEL the INVITE because it has completed. CANCEL is for cancelling a pending INVITE transaction, not a dialog. One or more early dialogs might be terminated as a side effect of the CANCEL, but its purpose is to terminate the INVITE transaction. BYE is used to terminate a dialog (early or confirmed). Also, 100 Trying responses do not have to-tags (because they are hop-by-hop), and the UAC can CANCEL the INVITE after receiving any 1xx response. > > now, *my UAC* decides to cancel this dialog, (this is *not* the UAS > which cancels), > as stated in 12.2.1.1:" > > The tag in the To header field of the request > MUST be set to the remote tag of the dialog ID. > Section 12 applies to requests within a dialog. A CANCEL is not a request within a dialog. > " > my UAC MUST use the toTag=C... > UAC ------------------> SENDS CANCEL (callID=A, fromTag=B, toTag=C) > -----------> UAS > In this case, you need to send BYE instread of CANCEL. > my UAS is then able to get back the dialogID=ABC and match the > session(dialog) to be cancelled. > For me, this is a very classical sequence... and I still do not see how > an UAC could send a cancel without using the toTag.... > > Thomas > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
