[asterisk-users] SIP/TCP?

[Tim Panton]

On 5 Jan 2007, at 23:22, Yuan LIU wrote:

>> From: "James R. Stevens" <jstevens at athensdistributing.com>
>>
>> TCP is a connection oriented protocol ..as others mentioned, it  
>> superiority comes because it knows when packets are dropped to  
>> resend them. It also has mechanisms for flow control etc.. SIP is  
>> a connection-less protocol. It uses 'best effort'  
>> transmissions..if u want its delivery guaranteed you must  
>> encapsulate it.
>
> So I take it that UDP is just a decision due to popular demand;  
> timing (jitter) is a frequently cited factor to favour UDP.  Is  
> there any technical difficulties in implementing SIP/TCP within  
> Asterisk?
>
> The reason I'm asking is that there are products that support both  
> UDP and TCP.  And SIP/TCP, RTP/TCP have their own merits.
>
> Granted, SIP is connectionless.  So is HTTP (well, for its original  
> design anyway).  I notice that guaranteed delivery could be a good  
> thing for SIP in many situations; there have also been advancements  
> that make timing less an issue in RTP/TCP.
>
> Is "switching to" SIP/TCP - RTP/TCP as simple as rewrap messages/ 
> streams, or is it more involved?


It's a latency thing.
Say you send a packet every 20ms
Say you have a pair of endpoints with 100ms between them.
Say you drop a packet in the media channel.

TCP will re-request the missing packet, which has 2
bad effects:
	1) when it does turn up the packet will be >100ms late so you have  
to play silence
		or make something up until it does.
	2) all the subsequent packets will be behind the re-tried packet and  
also 100ms
late. - Note that because TCP is a stream, you can't get at the  
subsequent packets
even if they turn up on time because you have to wait for the missing  
one.
Even more frustratingly you now have to dump these 4 perfectly good  
packets.
If you don't you will have introduced 100ms of lag in the audio stream.

- Of course none of this applies if you are on a LAN - with <1ms  
roundtrip time
as the retry can get to you soon enough to be useful.

With UDP you simply make something up for the missing packet and  
carry on when
you get the next one. - so you make up a single packet instead of 5.

With TCP the lost packet is multiplied by the ratio of the roundtrip  
time to the
packet interval.

Of course you can cover this up by increasing the buffering, but then
you are introducing yet more lag.

So, I simply don't think that TCP is suitable for telephony media  
streams over any
network where the roundtrip time is of the same order as the packet  
interval.

Now there are 'reliable datagram protocols' ( IL for example) but  
they aren't
much used on the internet.


Tim Panton

www.mexuar.net
www.westhawk.co.uk/