Subject: [SIP] RE: CANCEL - response sequence issue (again)

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Oct 2000 03:17:42 -0400

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 7:49 PM
> To: [email-masked]; Jonathan Rosenberg;
> [email-masked]
> Cc: [email-masked]; Vijay Gurbani
> Subject: CANCEL - response sequence issue (again)
> 
> Now, if we have a UAC (actual UAC or a virtual UAC branch on a proxy)
> that's coded according to the new bis but dealing with a UAS that's 
> coded according to the original RFC, the order of delivery suddenly
> becomes important if the UAC wants to clean state correctly.
> 
> Consider a UAC coded to the bis spec dealing with an old UAS coded to
> the RFC 2543 spec.  If the UAC sends a CANCEL, it will only 
> get the 200 
> OK (CSeq: xxx CANCEL).  So, it is done with the CANCEL/200 OK 
> transaction.  But it will never get the 487 Request 
> Terminated response 
> for it's original INVITE.  The UAC will not retransmit the 
> INVITE (since 
> it got the provisional responses), leading to inconsistent 
> call state in
> the UAC.
> 
> I think the bis should, in section 4.2.5 stress that, "...If 
> the server
> has not issued a final response for the original request, it 
> immediately
> sends a 487 Request Terminated for the original request.  The UAC 
> confirms receipt of any final response for the original request as 
> normal with an ACK request.  CANCEL request is answered with a 200 OK
> response in either case after the original transaction has completed."
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                         My suggested wordings; please re-word 
> if needed

No. Counting on order is a dangerous thing. Lets say a real final response
was sent, and then a CANCEL is received (crossing the final response on the
wire). The CANCEL is received, and responded to with a 200 OK. This 200 OK,
and the final response to the request, are received in the opposite order at
the client. The result is that the client thinks there won't be a response
to the original request, even though there is.

The correct solution is that you cannot *depend* on the receipt of 487 to
terminate the original transaction. You need to have a timeout which, after
sending CANCEL, terminates the transaction if no final response is received
before some X seconds. X can be fairly small, since either you will get a
final response right away (modulo some packet loss), in the case of bis
proxies, or never. We have this timer set to something like 5 or 6 seconds.

I do think the spec needs to talk about this. In fact, I recall that it was
raised on the list previously.

I would rather say:

For backwards compatibility with RFC2543, UACs and proxies which generate
\CANCEL \MUSTNOT assume that a 487 response to the original transaction will
be received. Instead, they \SHOULD set a timer upon sending \CANCEL, and
terminate the transaction if not response to the original request is
received after X seconds.

Now, the question is: what value for X? To deal with worst case network
losses, it could be as large as 32 seconds, but that results in very slow
timeouts. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 18 Oct 2000 09:31:58 -0500

> > From: Vijay K. Gurbani [mailto:[email-masked]]
[...]
> > I think the bis should, in section 4.2.5 stress that, "...If the 
> > server has not issued a final response for the original request, it
> > immediately sends a 487 Request Terminated for the original request. 
> > The UAC confirms receipt of any final response for the original 
> > request as normal with an ACK request.  CANCEL request is answered 
> > with a 200 OK response in either case after the original transaction 
> > has completed."
> > 
> No. Counting on order is a dangerous thing. Lets say a real final 
> response was sent, and then a CANCEL is received (crossing the final 
> response on the wire). The CANCEL is received, and responded to with a 
> 200 OK. 

But, Jonathan, this should NEVER happen.  If the UAS has sent out a 
final response AND THEN gets a CANCEL, per the bis, the CANCEL has no
effect on its state; it will ignore it and NOT send a 200 OK (CSeq: xxx 
CANCEL).  Meanwhile, the final response from the UAS arrives at the UAC, 
which figures out that this response is for the INVITE.  Thus it knows 
that the CANCEL it sent out has no effect and it can kill the CANCEL 
transaction, formulate an ACK and send that out and clean state for the
INVITE transaction as well (after 32 seconds, of course).

> This 200 OK, and the final response to the request, are received in 
> the opposite order at the client. The result is that the client thinks 
> there won't be a response to the original request, even though there 
> is.
> 
> The correct solution is that you cannot *depend* on the receipt of 487 
> to terminate the original transaction. 

I think the ordering is preserved by the protocol itself.  The UAS on 
getting a CANCEL will NOT transmit a 487 if it has already transmitted a 
final response prior to when the CANCEL arrived.

> You need to have a timeout which, after sending CANCEL, terminates the 
> transaction if no final response is received before some X seconds. X 
> can be fairly small, since either you will get a final response right 
> away (modulo some packet loss), in the case of bis proxies, or never. 
> We have this timer  set to something like 5 or 6 seconds.
>
> I do think the spec needs to talk about this. In fact, I recall that 
> it was raised on the list previously.
> 
> I would rather say:
> 
> For backwards compatibility with RFC2543, UACs and proxies which 
> generate \CANCEL \MUSTNOT assume that a 487 response to the original 
> transaction will be received. Instead, they \SHOULD set a timer upon 
> sending \CANCEL, and terminate the transaction if not response to the 
> original request is received after X seconds.

I really don't think we need to set a timer and converge on a value for 
X since that is just more complexity (at least) I can do without.  As 
far as I have worked this out, if a UAC CANCELs an INVITE and gets back 
200 OK (CSeq: xxx CANCEL), it can clean state of the INVITE as well 
since it will not be getting 487 for sure.  

The response cycle for the UAS appears straightforward -- the UAS MUST 
NOT send out a final response to the CANCEL if it got the CANCEL *after* 
sending a final response to an INVITE (or for any other method -- BYE, 
OPTIONS, for that matter).

Your comments?

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 18 Oct 2000 10:35:25 -0500

"Vijay K. Gurbani" wrote:
[...]
> > response on the wire). The CANCEL is received, and responded to with 
> > a  200 OK.
[...]
> effect on its state; it will ignore it and NOT send a 200 OK (CSeq: 
> xxx CANCEL).  

Hmmm...on closer introspection, my fault (should have read the draft 
more carefully).  While the CANCEL has no effect on the UAS's call 
state, the UAS *does* sent out a 200 OK (CSeq: xxx CANCEL).  So, the 
scenario Jonathan described about the 200 OK (CSeq: xxx CANCEL) arriving 
before the final response to the original transaction holds, as does the 
solution he described of waiting X seconds after getting the 200 OK 
(CSeq: xxx CANCEL).

To paraphrase what someone said on the list a while ago, "Jonathan, 
you're the man" :-)

Regards,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 20 Oct 2000 13:04:18 -0500

Dr. Schulzrinne:

Would it be possible to add what Jonathan Rosenberg suggests below for
backward compatibility in a CANCEL/200 OK/487 Request Terminated
scenario.  This appears to be the cleanest solution.  

I had thought that we could get something better by NOT having the UAS 
respond with a 200 OK when it gets a CANCEL cancelling a request for 
which it has already send a final response.  However, on closer 
inspection, this may not buy us much (I can share the analysis with 
whoever is interested).  I was trying to avoid choosing a timeout value 
for X (see attachment below) -- but no avail, the timeout will be 
needed to clean up transaction state.

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Oct 2000 18:02:00 -0400

> scenario.  This appears to be the cleanest solution.

Let me see if I can summarize the cases here:

- if call *was* established before CANCEL arrived (call exists)
  200 (INVITE) is returned within 32s in RFC 2543 or bis
  200 (CANCEL) is returned

- call failed before CANCEL arrived (no call in progress)
  4xx/5xx (INVITE) is returned
  200 (CANCEL) is returned

- if call was *not* yet established before CANCEL arrived (i.e., call
does not exist)
  200 (CANCEL) is returned
  487 (INVITE) is returned if -bis, nothing if RFC2543
  (arriving in either order)

This is presumably the case that is of concern. The UAC or proxy can't
tell whether the 200 (INVITE) is just late (first case) or will never
show up (third case, RFC2543).

For a proxy, would any state be needed, as long as the ACK can be
generated for any late 487?

For a UAC, may it have to wait the 32s just in case the call was
established after all?

I'm sure I missed something (coming in on the tail end of this
discussion).

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Oct 2000 10:53:46 -0500

Dr. Schulzrinne: 

Please see embedded comments:

> show up (third case, RFC2543).

Right.
 
> generated for any late 487?

Unless I am mistaken, state for the original transaction would be needed
if the proxy forked an INVITE request into n branches going downstream.
When it gets a 200 OK (INVITE) on one of its branches, it may forward
it upstream and send CANCEL downstream to n-1 branches.  It will need
to maintain state for these n-1 branches so it may respond with an
ACK if a 487 response gets to one of these branches (or kill the branch
after X seconds if all it got was a 200 OK (CANCEL) -- RFC 2543 
behavior).
 
> For a UAC, may it have to wait the 32s just in case the call was

Setting X to 32 is one solution; but as Jonathan points out, it will
lead to slow timeouts.  I wonder if UACs may *have* to wait 32 seconds,
just to be sure, and proxies, having sent a final response upstream to
a forked INVITE, may get by with waiting < 32 seconds (10, 20?) on the
rest of their branches.  In the worst case, the UAS will retransmit 487
until it gives up due to the non-receipt of an ACK (not terribly 
elegant, but any other suggestions?).

> > > generate \CANCEL \MUSTNOT assume that a 487 response to the 
> > > original transaction will be received. Instead, they \SHOULD set a 
> > > timer upon sending \CANCEL, and terminate the transaction if not 
> > > response to the original request is received after X seconds.
> > >
> > > Now, the question is: what value for X? To deal with worst case 
> > > network losses, it could be as large as 32 seconds, but that 
> > > results in very slow timeouts.
> > >
> > > -Jonathan R.

- vijay