Re: [Sip] Canceling REFER

[Cullen Jennings <fluffy@cisco.com>]

On 9/8/03 16:42, "Cullen Jennings" <fluffy@cisco.com> wrote:


I had some out of band discussion to track down the requirements on this. I
think the question actually turned into the the question of what happen when
you send a REFER to an early dialog. If the refer is accepted and a new
dialog is formed, I believe the old dialog should be ended - in this case
since it is an early dialog, it will be ended by sending a CANCEL.

Do folks agree on this? Thanks, Cullen


> 
> Before we continue the discussion on how to implement the time travel
> machine that P-RECALL-MISSLES will require, can anyone provide any reason we
> would need to cancel a REFER and perhaps we can just solve that problem
> instead.
> 
> 
> On 9/5/03 6:29, "Jiri Kuthan" <jiri@iptel.org> wrote:
> 
>> I think CANCEL would be better off. User's location can change before
>> P-RECALL-MISSLES or SUSCRIBE/0 is sent and land at a different destination
>> than the original REFER. CANCEL guarantees that you use the same
>> transport destination as the original request.
>> 
>> -Jiri
>> 
>> At 03:21 PM 9/5/2003, Tolga Asveren wrote:
>>> What about sending SUBSCRIBE with Expires=0 , as described in RFC3265.
>>> Afterall RFC3515 states also in 2.4.4 that for unsubscribing, the procedure
>>> described in RFC3265 is valid.
>>> 
>>>   Tolga
>>> --- "Mark Eastman (meastman)" <meastman@cisco.com> wrote:
>>>> Hello,
>>>> 
>>>> I have a question about how to deal with canceling a
>>>> REFER.  Let's say I
>>>> REFER Bob to Betty, but then decide I want to REFER
>>>> Bob to someone else
>>>> before the transfer is complete.  Are there existing
>>>> call flows describing
>>>> such behavior?  I know the REFER rfc states handling
>>>> multiple refers is
>>>> valid, but is that how one would handle this
>>>> situation (Sending a new REFER
>>>> with either a new target or perhaps method=CANCEL).
>>>> If so, call flows
>>>> describing such behavior would be nice.
>>>> 
>>>> Thanks,
>>>> Mark
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Sip mailing list
>>>> https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP
>>>> Protocol
>>>> Use sip-implementors@cs.columbia.edu for questions
>>>> on current sip
>>>> Use sipping@ietf.org for new developments on the
>>>> application of sip
>>> 
>>> 
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sipping@ietf.org for new developments on the application of sip
>> 
>> --
>> Jiri Kuthan            http://iptel.org/~jiri/
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip