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
>>>
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
