Subject: Re: [Sip] Canceling REFER

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 09:21:52 -0400

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

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 05 Sep 2003 15:29:22 +0200

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

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Robert Sparks <[email-masked]>
Date: 05 Sep 2003 08:46:59 -0500

>From RFC3515:

   Terminating a subscription,
   either by explicitly unsubscribing or rejecting NOTIFY, is not an
   indication that the referenced request should be withdrawn or
   abandoned.  In particular, an agent acting on a REFER request SHOULD
   NOT issue a CANCEL to any referenced SIP requests because the agent
   sending the REFER terminated its subscription to the refer event
   before the referenced request completes.

RjS

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 09:58:28 -0400

From RFC3515:
The implicit subscription created by a REFER is the same as a
subscription created with a SUBSCRIBE request.  The agent issuing the
REFER can terminate this subscription prematurely by unsubscribing
using the mechanisms described in [2].  Terminating a subscription,
either by explicitly unsubscribing or rejecting NOTIFY, is not an
indication that the referenced request should be withdrawn or
abandoned.  In particular, an agent acting on a REFER request SHOULD
NOT issue a CANCEL to any referenced SIP requests because the agent
sending the REFER terminated its subscription to the refer event
before the referenced request completes.

Are the second and third sentences not in conflict?

Because such a SUBSCRIBE is going to be sent also in the same dialogue, I
would think is a better option than a "NEVERMIND", because it will follow
the same mechanism as decribed in RFC3265.

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Robert
> Sparks
> Sent: Friday, September 05, 2003 9:47 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sip] Canceling REFER
>
>
> >From RFC3515:
>

---

From: Robert Sparks <[email-masked]>
Date: 05 Sep 2003 09:05:33 -0500

No, there is no conflict. The subscription can be terminated without
affecting the referenced request.

> the same mechanism as decribed in RFC3265.

A dialog is a dialog - sending any request on it is well defined. What
do you see different between a SUBSCRIBE and any other method in this
situation?

---

From: Robert Sparks <[email-masked]>
Date: 05 Sep 2003 08:46:26 -0500

Jiri - I posted earlier why CANCEL can't be made to work. Could you
respond to that (or let me know if it didn't get reflected by the
list server).

As for getting to the right endpoint, the NEVERMIND request could
be issued inside the dialog created by the REFER.

RjS

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 11:26:15 -0400

> Sent: Friday, September 05, 2003 10:06 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: RE: [Sip] Canceling REFER
>
>
[TOLGA] O.K. , I see, yes they are different things.
> do you see different between a SUBSCRIBE and any other method in this
[TOLGA]That was my point, that a SUBSCRIBE is also just a method inside a
dialogue. But because of the above -that SUBSCRIBE does terminate the
subscription, not the referenced request-, SUBSCRIBE is not a solution,
unless that behaviour is changed. But still, I would think, changing
semantics for SUBSCRIBE/0 -and allowing it to abandon a pending referenced
request- should work. What was the reason, not to allow SUBSCRIBE/0 to do
so?

---

From: Robert Sparks <[email-masked]>
Date: 05 Sep 2003 10:43:32 -0500

> request- should work. What was the reason, not to allow SUBSCRIBE/0 to do

Things like allowing endpoints that don't care about the result of the
reference (true "blind" transfer for example) to not have to take on
subscription state by rejecting the first NOTIFY.

RjS

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 5 Sep 2003 13:22:07 -0400

> Sent: Friday, September 05, 2003 11:44 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Even to cover such a case:
a)rejecting NOTIFY ===>go ahead with request but cancel the subscription
b)SUBSCRIBE/0 ====>if request is pending send CANCEL, and cancel the
subscription
seems working.
Now, the above just won't cover the case, where the initiator of REFER
decides *after it send the response for NOTIFY*, that it is no more
interested in the result of request but also does not want the request to be
cancelled.

---

From: Robert Sparks <[email-masked]>
Date: 05 Sep 2003 12:43:48 -0500

> interested in the result of request but also does not want the request to be

Hence, SUBSCRIBE/0 is really not where we want to go.
Among other things, it would take us (again) down a path where we
overload an operation to mean two things that really need to be
handled separately.

So - =IF= we want to pursue this, it really does need to be a new
method. Lets focus on that "if" for awhile instead of the mechanics
of "how".

What's the compelling first application of having such a tool?

RjS

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 08 Sep 2003 16:42:15 -0700

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.

---

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 9 Sep 2003 07:47:37 +0200

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: [email-masked] [mailto:[email-masked]] Im Auftrag von
Cullen
> Jennings
> Gesendet: Dienstag, 9. September 2003 01:42
> An: [email-masked]
> Betreff: Re: [Sip] Canceling REFER
> 
> 
> machine that P-RECALL-MISSLES will require, can anyone provide any
reason
> we

---

From: "Mark Eastman (meastman)" <[email-masked]>
Date: Tue, 09 Sep 2003 10:00:16 -0400

Hello,

The scenario is this.

A REFER has already been sent and the transferor has decided he/she wants 
to transfer the call somewhere else.  At this point in time the transferee 
will have received the REFER and sent out the triggered INVITE.  I don't 
see a way that this can be stopped.  The question is, is there a way the 
transferor can cause that triggered INVITE to be canceled?  Sounds like no 
with current methods.  A REFER with method CANCEL is insuffecient because 
the transferee has insufficient information about the call leg being 
canceled (No callid and tags).  What about another refer with a different 
target in the refer-to header (REFER within a REFER).  Is it safe to imply 
that this means canceling the previous triggered INVITE?  I would think not.

Thanks,
Mark

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Sep 2003 16:28:55 -0700

On 9/8/03 16:42, "Cullen Jennings" <[email-masked]> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 10 Sep 2003 19:53:50 -0400

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Cullen
> Jennings
> Sent: Wednesday, September 10, 2003 7:29 PM
> To: Cullen Jennings; [email-masked]
[TOLGA]And how to stimulate a CANCEL for an early dialogue, if we don't want
to do a new refer and just want to give up -and want the related dialogue to
terminate, if it is not confirmed-?

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Sep 2003 23:00:10 -0700

> terminate, if it is not confirmed-?

The problem I tracked down did not seem to require this. Do you have a
situation that does require this? Can you describe the requirements of what
you want to accomplish and perhaps we can figure it out. One possibility is
to transfer the dialog back to the sender of the refer then send a BYE to
end the dialog. 

Cullen

---

From: Robert Sparks <[email-masked]>
Date: Thu, 11 Sep 2003 09:21:53 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 11 Sep 2003 09:31:30 -0500

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

---

From: "Mark Eastman (meastman)" <[email-masked]>
Date: Thu, 11 Sep 2003 10:34:55 -0400

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:
> reason we

---

From: Robert Sparks <[email-masked]>
Date: Thu, 11 Sep 2003 09:44:09 -0500

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 Sep 2003 13:06:15 -0700

Sorry, I should have been more specific - I think we agree. I was only
discussion the replaces case not the general Refer case.