Forgot to mention, I am only talking about a OOD REFER.

Thanks
Ramesh

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

Reply via email to