There are issues which exist when using the interleaved frame header when rtp / rtcp is used under tcp interleaved and http funneled connections.
The character '$' 0x24 is specified as safe but its appearance during the reception of any non binary data causes framing issues which cannot be avoided easily.
See the following errata
http://www.rfc-editor.org/errata_search.php?eid=4199
In such situations it is possible to check payload type and ssrc to ensure the data content is relevant and parsed correctly.
If the data is not rtp or rtcp it is from a higher protocol such as rtsp.
Additionally the specification does not state the process for recovering from situations where the tcp mss did not encompass the transmitted frame.
In such situations if less than the bytes indicated by the header are available it is jot clear exactly what to do especially if further received data starts a new application frame header (which again is difficult to detect).
The same applies for more bytes received, should the next bytes be parsed as a new application layer header?
There are also issues in the draft, specifically where rtsp expansion is defined.
Ambiguous statements about the allowances for $ have been made but it shouldn't be present is a message at the binary level.
The statement about pdu fragmentation is ambiguous because the spec does not say how or why this can occur or how to handle those situations.
Last edit: juliusfriedman 2014-12-12