Re: [Sip] Canceling REFER

[Robert Sparks <rsparks@dynamicsoft.com>]

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