during the implementation and integration of SRTCP I stumbled over
some modifications that were checked in on July, 20th that enable
usage of RTP over TCP. In my not so humble opinion that is a bad idea
and is prone to fail or generate serious problems.
UDP is a datagram transport:
- if the receiver reads data then it gets the whole datagram (data)
in _one_ read - in the same way the sender sent it.
- it returns the correct length of the data that was sent by the
sender in _one_ write operation.
With UDP you either receive all the data that the other party sent
with with a datagram at once or you receive nothing, also the order
is not guaranteed in UPD.
In contrast to this TCP is a stream and thus it behaves different:
Using TCP the client may send 200 bytes and then, sometimes later another
200 bytes, and so on. Due to cirumstances that the client cannot control
the TCP implementation may decide to send:
- 2 times 200 bytes (as one would expect)
- it may also combine the data of both write operations and send 400 bytes
at once, and the receiver can read 400 bytes at once, not two times
- it may send 270 and 130, etc.
How a TCP implementation sends data depends on the implementation of TCP,
available resources, etc. Such scenarios may happen, for example:
- if the time between the two write operations is short (may happen in
Jitsi due to some JMF timing)
- some resources are not available to sent the first bunch of data
immediatley and is therefore delayed, for example in WLAN environments
where we have seen "bursts" of several UDP packets in a very short
timeframe. The TCP implementation may decide to combine these and optimize
the send stream
- many other circumstances where TCP may decide to send more or less data
Fact: reading from a TCP stream does not gurantee that you read the data in
the same way the sender sent it - in terms of packet/message size.
That's one big difference between a stream and a datagram transport.
Have a look at: http://en.wikipedia.org/wiki/User_Datagram_Protocol
and scroll down to the chapter "Comparison of UDP and TCP"
== Implications for RTP and RTCP ==
(S)RTP packets do not carry a length field (RFC 3550, chap 5.1). RTP
determines the length implicitly because it uses UDP and UDP informs the
receiver about the length of the datagram packet. A streaming transport
does not support this feature because it was not designed for that.
(S)RTCP carries length fields: one for each part of a compound RTCP packet.
RTCP does not have an indication how many parts a compund packet contains,
thus a TCP receiver cannot really decide when to stop reading. In SRTCP
only the very first length field is usable - all others are encrypted .
RFC 3550 uses UDP as transport, refer chapter 2 and it subchaptes.
== Proposal ==
I would ask to remove the TCP support for RTP to avoid any problems which
may cause non-deterministic errors and wrong behaviour.