[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Canceling REFER
I just had a small AHA moment.
For the application you are looking at, what if the second
REFER referred-to something like an INVITE-replaces, but instead
of trying to replace state at the thing receiving the invite, it
replaces state at the thing sending the invite?
RjS
On Thu, 2003-09-11 at 09:21, 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