Subject: RE: [Sip] Retransmission of INVITEs

From: "James Undery" <[email-masked]>
Date: Fri, 4 Oct 2002 10:49:18 +0100

I'd agree the probability of failure is small, however, the case I am thinking about is with an application server, that allows multiple service composition including 3pcc. The application server can't really control the latency introduced by applications and so the window of failure is larger than for a "vanilla" proxy, that combined with the automaton initiating the call is a cause for concern.

On the subject of expense of the change, switching to 100s causing T2 separated retransmissions and non 100 1xx stopping retransmission seems an inexpensive backwardly compatible change.

James

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]

> 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:
> 
> 
> >Igor Slepchin wrote:
> >>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.
> >
> >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
> >
> >_______________________________________________
> >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, 04 Oct 2002 11:15:38 +0200

At 03:19 AM 10/4/2002, Igor Slepchin wrote:
>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 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.

The problem is the previous hop thinks evertyhing is ok.

-Jiri

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 4 Oct 2002 12:12:22 -0400

The previous hop will realize there was a failure after timing out without
receiving a final response and can retry sending the request to a backup in
that case. This is fairly similar to non-INVITE failure case where the
previous hop will failover after transaction timeout though timeout in
INVITE case may admittedly be longer. The main difference is that in INVITE
case the previous hop may not know that the problem occurred in the next
hop, but if there is lots of traffic going on between these servers, the
previous hop most likely will have detected the failure by then anyway. 

In any case, if the application is really concerned about this kind of
failures, I think it can retransmit INVITEs even after a 100: not
retransmitting them is a SHOULD strength in the spec...

Thank you,
Igor Slepchin