[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Canceling REFER
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