The following draft might be helpful. It shows how to REFER a CANCEL and REFER a BYE.
http://www.ietf.org/internet-drafts/draft-mahy-sip-remote-cc-04.txt > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ramesh > Sent: Monday, January 08, 2007 11:14 AM > To: Paul Kyzivat; [email protected] > Subject: Re: [Sip-implementors] OOD REFER Dialog Termination > > Essentially what I am looking for is a method to Terminate > the Dialog created by a REFER Message from the Message > Originator. If BYE and CANCEL cannot be used to terminate the > REFER dialog What else can be used terminate it *from* the > originator? As REFER creates an implicit transaction can we > use SUBSCRIBE to terminate the REFER dialog? Or is there some > other mechanism to terminate the REFER dialog? > > Thanks > Ramesh > > PS: > Regarding BYE and CANCEL, I guess there is some RFC or Draft > that says we should not use BYE/CANCEL in scenario other than > INVITE, 3261 does not exactly forbid their usage for other > Dialogs/Transactions? If it is DailogUsage draft I will go > through it. If it is something else please correct me. > > > > > On 1/8/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > > > > > Ramesh wrote: > > > I think, we will send CANCEL/BYE in the Refer-to header only to > > Terminate > > > other dialogs. If we have to Terminate the REFER dialog itself we > > > don't > > have > > > to send it using another REFER Message. > > > > > > > BYE is a Dialog Terminator so we can send a BYE for the > REFER Dialog. > > > > BYE is *not* a dialog terminator - it terminates an invite > dialog usage. > > It never affects a REFER dialog usage. If an invite dialog > usage and a > > refer dialog usage share a dialog then a BYE will terminate the > > invite, but the dialog will remain until the refer dialog > usage is terminated. > > The refer dialog usage is terminated by the sending of a > NOTIFY that > > indicates the usage is ended. That can be requested by sending a > > reSUBSCRIBE for the refer event within the usage with an expiration > > time of zero. > > > > > Like BYE, CANCEL is a transaction Terminator. > > > > CANCEL also doesn't actually terminate a transaction. It *requests* > > that a transaction be terminated, but that request can be ignored. > > > > BYE doesn't terminate any transaction. > > > > This stuff is not clear in the RFCs. The dialogusage draft and the > > race-examples draft help clarify some of this. > > > > > Here is snipet from RFC3261 Section 5 about CANCEL "A TU that > > > creates a client transaction can also cancel it. When a > > client > > > cancels a transaction, it requests that the server stop further > > processing, > > > revert to the state that existed before the transaction was > > > initiated, > > and > > > generate a specific error response to that transaction. > This is done > > with a > > > CANCEL request, which constitutes its own transaction, but > > > references > > the > > > transaction to be cancelled (Section 9)." > > > AND from Section 9. > > > "The CANCEL request, as the name implies, is used to cancel a > > > previous request sent by a client. Specifically, it asks > the UAS to > > > cease > > processing > > > the request and to generate an error response to that request." > > > > > > Here is the call flow in my mind. > > > > Your call flows got mangled. I'm not going to attempt to guess what > > they attempt to show. > > > > Paul > > > > > 3PCC > > > ALICE BOB > > > ----------- > > > ----------- ----------- > > > | > > > | | > > > > > > |------------REFER----------------------------------->| > > > | > > > |<-------------------202 > > > ---------------------------------| > > > | > > > | > > > | | > > > | > > > |------------INVITE------------------------>| > > > |-------------BYE(for REFER > > > Dialog)----------->| > | > > > | > > > |------------CANCEL--------------------->| > > > |<-----------200 > > OK------------------------------------|<------------200 > > > OK ----------------------| > > > | > > > | | > > > | > > > |<----------487-------------------------------| > > > | > > > | | > > > > > > > > > > > > > > > Likewise in Section 15 RFC talks about Termination of > Session/Dialog > > which > > > is done by using BYE. > > > > > > I read the RFC and it does not explicitly address this issue. The > > > other option is that REFER creates an implicit > Subscription and we > > > could > > terminate > > > the subscription which would cause and end of the dialog too. The > > > only > > issue > > > with this solution is that we will have to deal with the > transaction > > > not being terminated when the subscription is terminated. > > > Call flow using subscription to > > > 3pCC Alice > > > --------- -------------- > > > | | > > > |--------(OOD) REFER--------->| > > > | | > > > |----Subscribe(Expire=0)----->| > > > | | > > > |<----------200 OK-----------------| > > > |<----------487(REFER)----------| > > > > > > > > > Thanks > > > Ramesh > > > > > > > > > On 1/4/07, Sanjay Sinha (sanjsinh) <[EMAIL PROTECTED]> wrote: > > >> You can not send a CANCEL to cancel REFER. You can send another > > >> REFER with method CANCEL/BYE in Refer-To header to terminate the > > >> dialog created as a result of initial REFER. That also > needs you to > > >> know the dialog identifiers of that dialog that you want > to cancel > > >> or bye. You can get that by subscribing to "dialog" > event package. > > >> > > >> Pl. see this: draft-mahy-sip-remote-cc-04.txt > > >> > > >> Sanjay > > >> > > >> > > >>> -----Original Message----- > > >>> From: [EMAIL PROTECTED] > > >>> [mailto:[EMAIL PROTECTED] On Behalf Of > > >>> Ramesh > > >>> Sent: Thursday, January 04, 2007 6:28 PM > > >>> To: [email protected] > > >>> Subject: [Sip-implementors] OOD REFER Dialog Termination > > >>> > > >>> Hi, > > >>> Here is another question I have with regard to Usage > of REFER in > > >>> 3pcc. If we have started a OOD-REFER and wish to CANCEL the > > >>> dialog; ie the originator of the dialog wishes the cancel the > > >>> Dialog. Can I send a CANCEL message if we have not received a > > >>> confirmation 2xx message and a BYE message if we have > received a > > >>> dialog Confirmation. I haven't seen anything in the RFC the > > >>> explicitly forbids me from doing it. > > >>> > > >>> > > >>> -- > > >>> cheers > > >>> ramesh > > >>> _______________________________________________ > > >>> Sip-implementors mailing list > > >>> [email protected] > > >>> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > >>> > > > > > > > > > > > > > > > -- > cheers > ramesh > _______________________________________________ > 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
