Ramesh,
To cancel the implicit subscription resulting from a REFER, send an
in-dialog SUBSCRIBE for the "refer" event package, with an expiration
time of zero. This is in the dialog resulting from the REFER. It also
must include the event-id of the implicit subscription, which will be in
the first NOTIFY, so you need to wait for that.
The subscribe will result in a final NOTIFY, which will terminate the
subscription. If the REFER was OOD, and you haven't done anything funny,
then that will be the only usage for the dialog and so the dialog will
go away as well.
Paul
Ramesh wrote:
> Forgot to mention, I am only talking about a OOD REFER.
>
> Thanks
> Ramesh
>
> On 1/8/07, *Paul Kyzivat* <[EMAIL PROTECTED]
> <mailto:[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]
> <mailto:[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]>
> >>> [mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>] On Behalf Of Ramesh
> >>> Sent: Thursday, January 04, 2007 6:28 PM
> >>> To: [email protected]
> <mailto:[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]
> <mailto:[email protected]>
> >>>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> <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
