Subject: RE: [Sip] Retransmission of INVITEs

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

At 06:12 PM 10/4/2002, Igor Slepchin wrote:
>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. 

Forking might work but dimensioning the "on_no_final_reply" timer is
a social issue which I would better avoid. It is simply not easy to 
distinguish between a failure and downstream server (or callee) which 
has not decided to send a final reply yet for INVITE. 

>This is fairly similar to non-INVITE failure case 

Not really as typically humans are not involved in non-INVITES
and loooong no_final_reply period of time is valid for INVITEs,
for example if the humans are government buerocrats or myself
seeking my cell in all my coat's pockets.

>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. 

A phone will have no heavy traffic.

>In any case, if the application is really concerned about this kind of
>failures, I think it can retransmit INVITEs even after a 100: 

I agree as for implementations -- that breaks nothing and you can 
label your implementation as "added-value reliability UAC" ;-)

As for the specification, the INVITE UAC state machine simply
ignores this case. That's why it was raised on [sip] and not
[sip-implementers] and deserves IMHO an improvement.

-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: Wed, 09 Oct 2002 01:47:10 -0400

> [sip-implementers] and deserves IMHO an improvement.

Well, it doesnt ignore it - it merely lumps it into another case (called 
party never answers) which requires the UAC at some point to give up and 
cancel. So, there is a call failure here when possibly there need not 
be. Thats not a bug in the spec, its a potential new feature if you want 
to add support for it.

Anyway, nitpicks like that aside, there are some side effects to the 
proposed solution. Presumably, on retransmitting the INVITE and getting 
a failure, the client would try a backup server. Now, the problem is 
that the client cannot distinguish the case where the proxy failed 
before proxying the request, or after (but in both cases, before a final 
response or non-100 1xx). If it fails after proxying, trying a backup 
effectively results in a forked request. This can have unintended 
consequences. In a PSTN termination case, two PSTN gateways might get 
copies of the forked INVITE and then both make calls into the PSTN. If 
these happen to be for an 800 number or multiline call, you end up with 
potentially two calls created. Granted, one of them should be cancelled, 
but this is still undesirable behavior.

My other concern is that the solution is UDP specific, and doesn't work 
for TCP. If we want to support this failure case for TCP, and we further 
assume failures without graceful closing of the connection, the client 
won't detect the failure as Henning pointed out. We could retransmit the 
INVITE on the TCP connection (yuck!), which is effectively like 
implementing application layer keepalives over TCP. I wonder what is the 
issue with TCP keepalives that make them infrequently used?

Also, the retransmits over UDP exacerbate the bandwidth consumption of 
SIP for the common case where there is no failure. I guess this is not 
too bad if you stop retransmitting after non-100 1xx...

-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: Jiri Kuthan <[email-masked]>
Date: Mon, 14 Oct 2002 12:43:35 +0200

Hard to parse -- what are you exactly proposing to solve 
lost UDP/INVITE?

Thanks,

-Jiri

At 07:47 AM 10/9/2002, Jonathan Rosenberg wrote:

>>I agree as for implementations -- that breaks nothing and you can label your implementation as "added-value reliability UAC" ;-)
>Well, it doesnt ignore it - it merely lumps it into another case (called party never answers) which requires the UAC at some point to give up and cancel. So, there is a call failure here when possibly there need not be. Thats not a bug in the spec, its a potential new feature if you want to add support for it.
>
>Anyway, nitpicks like that aside, there are some side effects to the proposed solution. Presumably, on retransmitting the INVITE and getting a failure, the client would try a backup server. Now, the problem is that the client cannot distinguish the case where the proxy failed before proxying the request, or after (but in both cases, before a final response or non-100 1xx). If it fails after proxying, trying a backup effectively results in a forked request. This can have unintended consequences. In a PSTN termination case, two PSTN gateways might get copies of the forked INVITE and then both make calls into the PSTN. If these happen to be for an 800 number or multiline call, you end up with potentially two calls created. Granted, one of them should be cancelled, but this is still undesirable behavior.
>
>My other concern is that the solution is UDP specific, and doesn't work for TCP. If we want to support this failure case for TCP, and we further assume failures without graceful closing of the connection, the client won't detect the failure as Henning pointed out. We could retransmit the INVITE on the TCP connection (yuck!), which is effectively like implementing application layer keepalives over TCP. I wonder what is the issue with TCP keepalives that make them infrequently used?
>
>Also, the retransmits over UDP exacerbate the bandwidth consumption of SIP for the common case where there is no failure. I guess this is not too bad if you stop retransmitting after non-100 1xx...
>
>-Jonathan R.
>--

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Oct 2002 15:25:45 +0300

Jonathan,

> I wonder what is the

As Henning pointed out, they are seldom turned on. The problem is that
TCP keep-alives can terminate an alright TCP connection when there are
transient network failures.

For example, if we are playing a chess game over TCP, our TCP connection
may be open during days. If at the moment your TCP stack is sending me a
TCP keep alive my access router has crashed, we will lose the connection
because your TCP stack will time out and release it. However, 5 minutes
later my access router is OK again, and we could have gone on playing
for days...

Note, however, that TCP keep-alive time outs are in the order or hours
(two hours is a common value). SIP timeouts at establishment time are
much smaller.

Folks against TCP keepalives usually claim that this type of keepalive
mechanism belongs to the application layer rather than to the tranport
layer.

Regards,

Gonzalo