Subject: [Sip] Canceling REFER

From: "Mark Eastman (meastman)" <[email-masked]>
Date: Thu, 04 Sep 2003 15:30:37 -0400

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: 04 Sep 2003 15:29:18 -0500

There is no defined "Stop trying to access the resource I've REFERed
you to" mechanism. REFER is not designed to be a remote-control for
a peer endpoint.

CANCELing the REFER won't make sense - the REFER is accepted or
rejected immediately and processing the reference happens after
that - the REFER transaction is already gone.

Attempting to construct a REFER to a CANCEL that would match an
INVITE triggered by a previous REFER is difficult. You don't have
the appropriate Call-ID/tags handy and even if you could get them,
there's language in the REFER draft that encourages an agent accepting
a REFER to ignore them.

So - if this functionality is something that we have a real need for,
its a new method (NEVERMIND perhaps?).

RjS

---

From: Sean Olson <[email-masked]>
Date: Thu, 4 Sep 2003 14:38:23 -0700 (PDT)

A REFER with a method=CANCEL sounds like an
interesting option. The call flow should not be
difficult to come up with
.
--- "Mark Eastman (meastman)" <[email-masked]>
wrote:
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 04 Sep 2003 20:54:37 -0400

> difficult to come up with
I suggest we call this either "RECALL-MISSLES" or "ZEN-REFER" (the Refer 
that un-refers the previous refer).

Dave.

>> describing such behavior would be nice.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Sean Olson <[email-masked]>
Date: Thu, 4 Sep 2003 22:43:31 -0700 (PDT)

Don't you mean P-RECALL-MISSLES?

--- "David R. Oran" <[email-masked]> wrote:
> >> 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
> >> with either a new target or perhaps
> method=CANCEL).
> >> If so, call flows
> >> Use [email-masked] for
> questions
> >> on current sip

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 08 Sep 2003 02:15:14 +0200

>its a new method (NEVERMIND perhaps?).

On the contrary to what I posted before, I agree CANCEL is not applicable
here. I didn't realize that REFER creates dialog.

What I'm not sure about is how to NEVERMIND forked out-of-band REFERs.
In such a case, dialog is established to forking winner and NEVERMIND
does not reach the other branches.

-jiri