[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [Sip] Canceling REFER
I think Cullen is right.
If you do care about the caller, you do an attended transfer.
The "blind" transfer with the option to recall missiles can be
implemented using an attended transfer:
1) Put "A" on hold by referring him to the entertainment server
2) call "B"
3) upon reception of 18x from B refer A to the ringback server
4) upon reception of 2xx from B refer A to B using Replaces
5) upon reception of 3456xx from B pick up the call again
6) upon wish to cancel, cancel the call to B and get A back
My only concern would be speed, especially the experience of B when
picking up that call.
CS
> -----Ursprüngliche Nachricht-----
> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
Cullen
> Jennings
> Gesendet: Dienstag, 9. September 2003 01:42
> An: sip@ietf.org
> Betreff: Re: [Sip] Canceling REFER
>
>
> 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