Re: H264 and wrong SDP payload types assumption in RFC 6184

I don't think it's mandated in either RFC 6184 or RFC 3264. In both places
it's only a "SHOULD".

Section 6.1 of RFC 3264:

   In the case of RTP, if a particular codec was referenced with a
   specific payload type number in the offer, that same payload type
   number SHOULD be used for that codec in the answer.

"SHOULD" means "the rule can be ignored under certain circumstances"; it's
not hard and binding. There are cases where, in fact, a matching payload
type *must not* be present in the answer. Suppose I offer codec A with PT
X. Later, the other endpoint offers me codec B with PT X. In our answer, we
must choose a different PT for codec B, because we're already using PT X
for codec A.

Admittedly, Chrome's WebRTC implementation still has some corner-casey bugs
around this (such as for the scenario described above:
https://bugs.chromium.org/p/webrtc/issues/detail?id=5847). But we're aware
of them, and definitely intend to support payload types not matching
between the offerer and answerer. Our video engine/audio engine are already
designed this way.

On Fri, Jun 17, 2016 at 4:25 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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>
>
>