Subject: Re: SIP over TCP question

From: Sean Olson <[email-masked]>
Date: Wed, 25 Aug 1999 16:58:01 -0500 (CDT)

> When running SIP over TCP, what should the UAC do if he does not see
> any response within 500 ms of sending the INVITE ?
> 
> 1 Just terminate the session

After 500ms.... I guess that's highly dependent on your particular 
application, but in general, no.

> 2 Wait for another second ( Even UDP will not wait for more than 3 
> seconds, since UDP client will get a ICMP error on the second
> or third INVITE).
>

This is not the same situation as a UDP client receiving an ICMP error.
Based on the reasons given in section 10.5 "Reliability for INVITE Requests",
I would argue that you should wait the same amount of time that you would
wait for UDP, you simply would not re-transmit the INVITE. In other words,
approx. 63 1/2 seconds (1/2 + 1 + 2 + 4 + 16 + 32)
 
> Thanks,
> -- 
> Best regards,
> Shail

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Aug 1999 14:03:42 -0400

> approx. 63 1/2 seconds (1/2 + 1 + 2 + 4 + 16 + 32)

If there is no server listening on the port, you won't be able to open
the TCP connection anyway, so you'll get an error right away. If the TCP
connection can be opened, but you get no response to the INVITE, I agree
probably you should wait the 64 seconds and then give up.  Don't
retransmit the request, though, since it doesn't do any good (the server
will get it the first time because of TCP). Probably we should add a
sentence to this effect in the spec.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 31 Aug 1999 14:11:43 -0400

> sentence to this effect in the spec.

The spec already spells out that TCP requests are not retransmitted. Is
there a need to specify a definite timeout interval? It seems like
that's strictly up to the patience of the client. If a client believes
that it is going to get a response after two hours, why keep it from
doing that?

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

---

From: Scott Petrack <[email-masked]>
Date: Tue, 31 Aug 1999 15:13:17 -0400 (EDT)

> sentence to this effect in the spec.

I've always disliked all statements like "over UDP do this, but over TCP
do that." It might be wasteful to retransmit over TCP, but then again,
maybe not. Maybe the TCP got the bytes, but somehow the application never
gets them, or makes a mistake putting the bytes back together into SIP
requests....

Can't we just say that SIP is independent of the underlying transport, be
it UDP, TCP or carrier-pigeon? And that correct SIP retransmission code
is a part of SIP. Will we need to add to the draft how/when to
retransmit if FedEx is used instead of carrier-pigeon?  (Maybe the package
will arrive, but the secretary will forget to give it to me....).

I would also like to train people to have correct retransmission timer
code in their implementations. Suppose today I write none because I am
running on TCP, so I "dont have to worry about retransmissions". Then
tomorrow I replace TCP by UDP. Chances are I'll write crappy
retransmission timers, because I want to make a "minimal change". Let's
just tell people to retransmit properly in the same way all the time.

Sorry for the rant.

Scott

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 31 Aug 1999 16:14:01 -0500 (CDT)

>gets them, or makes a mistake putting the bytes back together into SIP

And you think your application will do a better job of ensuring 
reliability than TCP? Surely you jest.

The only reason I can ever see anyone implementing a SIP node using
TCP is to avoid the issues of ensuring reliability (although I'll
admit this is somewhat ruined by the fact that an ACK can follow
its own path, so INVITE final responses need retransmission; but that's
another issue [which, incidentally, could be trivially solved by
the obvious method of forcing ACKs to follow the same path as their
corresponding INVITEs]).

If the distinctions bother you, I'd propose that you should be railing 
against the presence of multiple transmission types in the protocol
instead of the differences between them.

>will arrive, but the secretary will forget to give it to me....).

The distinction being made is between two fundamentally different types
of transport: reliable (confirmed) vs. unreliable. For an unreliable
transport, it is the application's responsibility to ensure that
a packet has been received and acknowledged. For a reliable transport,
all of that work is already done "behind the curtain." There is no
point in duplicating it.

To address your specific points (and others): 

Carrier pigeon              -- Unreliable -- Retransmit
FedEx w/office secretary    -- Unreliable -- Retransmit
RDP/IP                      -- Reliable   -- Don't retransmit
Raw RS-232                  -- Unreliable -- Retransmit
ATM w/assured operation     -- Reliable   -- Don't retransmit
ATM w/non-assured operation -- Unreliable -- Retransmit
MDTP/IP                     -- Reliable   -- Don't retransmit

And so on. It's not a difficult distinction to make.

>just tell people to retransmit properly in the same way all the time.

If you'll write crappy retransmission timers when adding UDP, I'd
bet good money that you'll write crappy retransmission timers the
first time around anyway.

People will write crappy code no matter how you attempt to socially
engineer them. More importantly, that's not our job.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA