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
