H264 and wrong SDP payload types assumption in RFC 6184

Hi,

RFC 6184, "RTP Payload Format for H.264 Video", states in section 8.2.2:

---------------------
To simplify the handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be used
in the answer, as specified in RFC 3264
---------------------

That is wrong. RFC 3264 does not mandate the same payload
type in both the offer and the answer. In fact, RFC 3264 section 5.1 states:

---------------------
For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.

However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.
---------------------

I've reported the issue in the IETF Editor:

https://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4714

It worries me whether WebRTC implementations may fail due to this
wrong assumption. Basically, if a browser generates a SDP offer with
PT 101 pointing to a H264 codec, and the SDP answer indicates PT 102
for the same codec+configuration, matching rules stateddefined in RFC
6184 are broken (while SDP rules in RFC 3264 are perfectly satisfied).

Are vendors aware of this?



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 17 June 2016 11:26:49 UTC