[asterisk-users] SIP/TCP?

[Julio Arruda]

SIP over TCP != RTP over TCP
The whole latency deal is much more of a concern in RTP (as well as 
trying to deliver a late packet, that will be not very useful also).
As I understand, MS does SIP/TCP on their LCS or something like that.
Still, not RTP over TCP, since it does not make sense for the voice-path.

Tim Panton wrote:
> 
> 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/
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users