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" <[EMAIL PROTECTED]>
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
_______________________________________________
--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
