Subject: RE: [SIP] OK with no ACK

From: "Vakil, Mohammad" <[email-masked]>
Date: Thu, 6 Jul 2000 10:57:36 -0400

Vijay - 

How can a User Agent Server issue a Cancel? What Dvir is describing here is
a UAS is trying to send 200 OK and never receives an ACK. It should just
kill the call without having to send anything after retransmission time out.

Mohammad Vakil
OutReach Technologies

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]]
Sent: Thursday, July 06, 2000 10:33 AM
To: Dvir Oren
Cc: SIP
Subject: Re: [SIP] OK with no ACK

Dvir Oren wrote:
> 
> I think that a situation where the calle sent OK, but doesn't receive
> ACK for an extended period of time should be handled.  I'm
> implementing a timeout on OK replies, that will kill the call if no
> ACK was received after a defined period of time.
> 
> My question is, should I send a CANCEL or a BYE?

I would send a CANCEL since the call has not been established until the
ACK from the caller gets to the callee.  That is the behavior of my
proxy.  A BYE (to me at least) conveys that a session was successfully
established and is now being torn down.

Regards,

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

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2000 11:18:45 -0400

I think Vijay is saying that his proxy sends a CANCEL if it doesn't see
the ACK before the timeout fires. Note that this will not do anything
useful, since the final response has already been sent by the UAS.
CANCEL requests a UAS to send a 487 to the original request if the
original request has not been responded to. In this case, it has been
responded to, with a 200 OK. So, CANCEL has no effect.

Mohammed is also correct that the UAS never sends a CANCEL for a request
it receives.

THe proper behavior here is for the UAS to consider the call
disconnected if it does not receive ACK even after having sent the 7 (or
whatever it is) 200 OK responses. This does mean that the UAC will
believe the call up, and the UA believe it down. You might think
responding to ACK might have helped this problem, but it doesn't. Its
the classic byzantine armies (or is it byzantine generals?) problem in
network protocols. The state inconsistency only arises in catastrophic
network failures; things like session timer will quickly discover these
things and result in BYE.

Having the called party send BYE might not help either. Thats because
the failure could be because the 200 OKs are all getting lost (in which
case the BYE doesn't help), or the ACKs getting lost (in which case the
BYE would help).

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 06 Jul 2000 10:06:22 -0500

"Vakil, Mohammad" wrote:
> 
> Vijay -
> 
> How can a User Agent Server issue a Cancel? What Dvir is describing 
> here is a UAS is trying to send 200 OK and never receives an ACK. It 
> should just kill the call without having to send anything after 
> retransmission time out.

Mohammad:

You are correct; I mistook Dvir's scenario for another context that I
have been thinking about recently (when you have a hammer, everything
looks like a nail...).  Clearly, in case of an INVITE if the caller does 
not receive an ACK to the 200 OK, it will keep on re-transmitting the 
200 OK until it has exhausted its retry limit.

Sorry for the confusion

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 06 Jul 2000 14:55:27 -0500

Jonathan Rosenberg wrote:
> 
> I think Vijay is saying that his proxy sends a CANCEL if it doesn't 
> see the ACK before the timeout fires.
[...]
> Mohammed is also correct that the UAS never sends a CANCEL for a 
> request it receives.

Jonathan:  Please read; there's a question for you towards the end.

When I read Dvir's original question, which was -- "should I send a 
CANCEL or a BYE?" -- I assumed he was asking what should the CALLER do 
after sending out an INVITE and not yet receiving a 200 OK.  So, in 
that context, I think after the seventh retransmission attempt (for UDP) 
or an appropriate timeout (for TCP), the caller should send a CANCEL 
and NOT a BYE.  As I said before, to me a BYE is semantically equivalent 
to the fact that an session was established already which is now being
torn down. A CANCEL cancels a pending request (i.e. a request for which 
a final status response has not been received yet).

However, the RFC (June 9 bis, Section 10.5.1) says that a UAC may send a 
BYE or CANCEL after the seventh retransmission.  RFC 2543 is silent on 
this (Section 10.5.1).  

Jonathan: don't know if you will recall, but during April 2000 bakeoff, 
I had a conversation with you where I came to the conclusion that CANCEL
is the appropriate request to send in this case.  But the June 9 bis
RFC indicates that a BYE is just as appropriate.  Should we finalize on
one of CANCEL or BYE in cases like this?  Or is it too much trouble to
codify such cases and prescribe behavior?

Thanks,

- vijay

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Jul 2000 16:17:06 -0400

> codify such cases and prescribe behavior?

It just doesn't matter. In either case, the callee (receiver of the BYE)
will remove call state, if any existed. The only drawback of CANCEL is
that there is a small chance that the callee had sent a 200 and all of
them got lost. The callee will then ignore the CANCEL. In that case,
you'd have to send a BYE when the 200 arrives, which is more trouble.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2000 00:13:24 -0400

> you'd have to send a BYE when the 200 arrives, which is more trouble.

We have discussed the issue before, and agreed during the meetings to
allow both, as currently specified. Here is the issue.

If the caller wants to hang up a call, but hasn't yet received a final
response, it can send a CANCEL or a BYE. Sending a BYE would seem
easiest, but there are issues. First off, you won't have gotten a tag
yet from the UAS, nor will you have received Record-Route or Contact
headers (obtained in the 200 OK response). This means the BYE will be
routed "afresh" by proxies. Its possible that routing logic may have
changed (perhaps there was some time of day routing or randomized
routing), in which case the BYE may reach a different set of
participants than reached by the original INVITE. So, if the original
INVITE forked, and reached A and B, and the BYE reaches B and C, B will
send a 200 OK, and C a 481. The forking proxy forwards the 200 OK
upstream, and the caller gets the 200 OK. However, A is still ringing,
and might later send a 200 OK. This yield inconsistent call state, which
will persist until the UAS times out, as it will never get an ACK. 

Sending CANCEL helps solve many of these problems. CANCEL will reach the
same set of recipients as the original INVITE, and it doesn't need a
REcord-Route or tag in it. The drawback, however, is that the CANCEL and
a 200 OK from one of the UAS might pass on the wire. Thus, the UAC may
still need to ACK the 200 OK, and then send BYE. The other drawback is
that you wouldn't send CANCEL if the call was already established, you'd
send BYE. Folks complained they didn't want to have state-dependent
mechanisms for hanging up. Given the unlikelihood of the problems with
sending BYE, it seems reasonable to allow it.

-Jonathan R.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 07 Jul 2000 11:31:25 -0400

Jonathan Rosenberg wrote:
> response, it can send a CANCEL or a BYE. 

It can also send both CANCEL and BYE to get the best of both worlds.
Note that this takes nearly no extra time since you can send BYE right
after CANCEL. I don't really see the problem with having this behavior
dependent on the state: the state has to be maintained anyway, right?
And I don't think that an extra "if" statement complicates things all
that much.

Thank you,
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jul 2000 01:00:33 -0400

> And I don't think that an extra "if" statement complicates things all

I don't think sending both at the same time really helps. The BYE still
won't have tags or be routed with route headers, and thus may still miss
some endpoints. Should the CANCEL pass a 200 OK on the wire (from an
endpoint which didn't get the BYE), well, you still have inconsistent
state. Sending CANCEL, and then BYE once 200 OKs come, is the only
sure-fire way to not have inconsistent state.

-Jonathan R.