Subject: RE: [Sip] Retransmission of INVITEs

From: Igor Slepchin <[email-masked]>
Date: Thu, 3 Oct 2002 21:19:18 -0400

I'm actually not sure this problem needs to be solved at transport level.
Even TCP does not provide this kind of reliability - if a TCP segment gets
ACK'ed by the TCP stack and then never delivered or processed to/by the
application, say, because the box dies, the sending application will think
the message was delivered.

The way I see it, the scenario is not that much different from the proxy
failing after forwarding the INVITE when response failover is not available.
In both cases the previous hop will need to detect a failure and take some
action to recover.

Thank you,
Igor Slepchin

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> 
> I don't understand what you don't understand.
> 
> The problem is an INVITE gets lost, nobody learns that,
> caller gets never a final reply and eventually hangs up
> even if there is a callee willing to have a call and
> restarted proxy willing to help set up the call.
> 
> I think James' T2 proposal is fair enough.
> 
> -Jiri
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Oct 2002 01:55:47 -0400

> the message was delivered.

I'm also not sure the problem needs to be solved, but for a different 
reason. It takes very specific timing to manifest itself; a proxy has to 
fail at the very instant between sending a 100 and proxying a request. 
Response failover, which SIP does provide, is meant to address failures 
between proxying a request and receiving a response, but the duration of 
that window of opportunity is orders of magnitude larger.

That said, the problem is more easily solved with TCP. If a client opens 
a TCP connection to a server, sends a request, but the connection closes 
before getting a non-100 response, it opens a connection to a backup 
server.  One can argue that this failure case is already covered in 
section 4.3 of rfc3263, although this was not really the intent.

In the case of UDP, it does require behavior akin to what James is 
proposing. An alternative would be to send the 100 after proxying the 
request. In any case, if we are moving away from UDP in the draft 
version of SIP, its not clear we need to solve this problem for UDP when 
a TCP solution is trivial.

-Jonathan R.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Oct 2002 08:28:32 -0400

> section 4.3 of rfc3263, although this was not really the intent.

This isn't quite true in all cases. If the server crashes without saying 
farewell at the TCP level, the caller side wouldn't notice. If the 100 
has been ACK'ed at TCP level, the caller's TCP is not waiting for 
anything and thus will gladly sit there doing nothing for months. (I'm 
ignoring TCP-level keep-alives which are rarely turned on and have much 
longer timescales as well as their own set of problems.)

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 04 Oct 2002 11:28:54 +0200

I agree the probability of this failure is low and fixing it
is expensive. Note that the failure can even occur in your 
counterexample, when proxy's outbound request gets lost,
and that the implementation order first-relay-then-100
breaks stopping retransmissions asap using 100.

So the question is still whether this little robustness
risk is worth the extra retransmissions.

My 2 cents are reliability is good even if expensive.

-Jiri

At 07:55 AM 10/4/2002, Jonathan Rosenberg wrote:

>I'm also not sure the problem needs to be solved, but for a different reason. It takes very specific timing to manifest itself; a proxy has to fail at the very instant between sending a 100 and proxying a request. Response failover, which SIP does provide, is meant to address failures between proxying a request and receiving a response, but the duration of that window of opportunity is orders of magnitude larger.
>
>That said, the problem is more easily solved with TCP. If a client opens a TCP connection to a server, sends a request, but the connection closes before getting a non-100 response, it opens a connection to a backup server.  One can argue that this failure case is already covered in section 4.3 of rfc3263, although this was not really the intent.
>
>In the case of UDP, it does require behavior akin to what James is proposing. An alternative would be to send the 100 after proxying the request. In any case, if we are moving away from UDP in the draft version of SIP, its not clear we need to solve this problem for UDP when a TCP solution is trivial.
>
>-Jonathan R.
>
>
>--