[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Canceling REFER
Sorry, I should have been more specific - I think we agree. I was only
discussion the replaces case not the general Refer case.
On 9/11/03 7:44, "Robert Sparks" <rsparks@dynamicsoft.com> wrote:
> Correct. As an example, imagine that I am in an INVITE created dialog
> with my conference server and I want to send it REFERs to bring both
> you and Cullen into this same conference. I don't want to have my
> INVITE to Cullen CANCEL my INVITE to you.
>
> RjS
>
> On Thu, 2003-09-11 at 09:34, Mark Eastman (meastman) wrote:
>> So basically, you feel receiving a REFER within another REFER dialog,
>> should not cause the triggered INVITE from the first REFER to be canceled?
>>
>> Thanks,
>> Mark
>>
>>
>> At 09:21 AM 9/11/2003 -0500, Robert Sparks wrote:
>>> This would close the door on any applications that would try to
>>> send REFERs to more than one destination (inside a given dialog)
>>> at once. I don't think that would be good for us in the long run.
>>>
>>> RjS
>>>
>>> On Wed, 2003-09-10 at 18:28, Cullen Jennings wrote:
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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