Subject: [rtcweb] Codec PT mismatch during renegotiation, valid or not?

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2016 12:36:27 +0200

Hi,

The following scenario causes setLocalDescription() to fail after
renegotiation because the re-offerer (Firefox) introduces new codec PT
in the same m= line):

1) Chrome calls to Firefox with an audio track. SDP offer (simplified):

m=audio 58234 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
a=setup:actpass
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000

2) Firefox SDP answer:

m=audio 65515 UDP/TLS/RTP/SAVPF 111
a=recvonly
a=fmtp:111 maxplaybackrate=48000;stereo=1
a=mid:audio
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=setup:active

Firefox has chosen PT 111 (opus). Fine.

3) Firefox re-offers with its own audio track. SDP re-offer:

m=audio 65515 UDP/TLS/RTP/SAVPF 109 9 0 8 111
a=sendrecv
a=fmtp:111 maxplaybackrate=48000;stereo=1
a=mid:audio
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 opus/48000/2
a=setup:actpass

Here Firefox has introduced a new PT value: 109 (also opus). Note that
PT 111 (opus) is still present.

4) Chrome gets the SDP re-offer, calls setRemoteDescription()
(success) and calls createAnswer(), which produces the following SDP
answer:

m=audio 58234 UDP/TLS/RTP/SAVPF 109 9 0 8
a=setup:passive
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=fmtp:109 minptime=10;useinbandfec=1
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

Note that Chrome has chosen PT 109 (opus) instead of the previously
used PT 111 (opus).

5) Then Chrome calls to setLocalDescription() with such an answer,
which produces this error:

> Uncaught OperationError: Failed to set local answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set local audio description recv parameters.

So my main question is: can an endpoint perform a PeerConnection
renegotiation and introduce new PT values within an existing m= line?
AFAIR this is NOT valid.

- If valid, then this is a Chrome bug.
- If invalid, then this is a Firefox bug.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2016 12:41:52 +0200

> renegotiation and introduce new PT values within an existing m= line?

Related issue in rtcweb-wg: https://github.com/rtcweb-wg/jsep/issues/266

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 8 Sep 2016 12:48:29 +0200

> - If invalid, then this is a Firefox bug.

Seems valid according to rfc3264:

8.3.2 Changing the Set of Media Formats

    The list of media formats used in the session MAY be changed.  To do
    this, the offerer creates a new media description, with the list of
    media formats in the "m=" line different from the corresponding media
    stream in the previous SDP.  This list MAY include new formats, and
    MAY remove formats present from the previous SDP.  However, in the
    case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session.  For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session.  However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2016 12:54:05 +0200

>    codec, so that an updated offer could also use payload type number 72

Sure. The problem is that such a requirement/feature seems a bit
"constrained" in WebRTC, at least according to the discussion in:

https://github.com/rtcweb-wg/jsep/issues/266

In that discussion new rules are proposed, so I just don't believe
that current browsers respect the 8.3.2 section above...

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 8 Sep 2016 13:07:25 +0200

> that current browsers respect the 8.3.2 section above...
It should be still valid based on current jsep draft:

5.2.2.  Subsequent Offers
    o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
       only include codecs present in the most recent answer.

Except if it is a typo and it was meant to read "payload types" and not 
"codecs".

Best regards

Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2016 13:12:58 +0200

> Except if it is a typo and it was meant to read "payload types" and not

IMHO that's the point:

- What do authors mean with "codec"?
- What do browser implementors understand?

BTW issue open in Chrome project because setLocalDescription() MUST
always work after a successful createAnswer():

https://bugs.chromium.org/p/chromium/issues/detail?id=645062

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 8 Sep 2016 08:30:45 -0400

> - What do browser implementors understand?

'codec' means the codec specified in the rtpmap.  It does not refer to 
the configuration of the codec as specified for a specific payload 
type.  You can have N payload types for the same codec, each with 
different (or even the same) configuration (typically in a=fmtp lines, 
though some others can affect it IIRC).

In this case, it's an innocuous bug in Firefox that it offers two 
payloads for the same codec/configuration in this situation. There's a 
real bug (as you note) in Chrome with not accepting their own Answer SDP.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2016 16:26:16 +0200

2016-09-08 14:30 GMT+02:00 Randell Jesup <[email-masked]>:
> 'codec' means the codec specified in the rtpmap.  It does not refer to the
> configuration of the codec as specified for a specific payload type.  You
> can have N payload types for the same codec, each with different (or even
> the same) configuration (typically in a=fmtp lines, though some others can
> affect it IIRC).

Thanks, clarified.

> In this case, it's an innocuous bug in Firefox that it offers two payloads
> for the same codec/configuration in this situation.

There's a real bug (as
> you note) in Chrome with not accepting their own Answer SDP.

Note that they are not the "same codec configurations" (although AFAIK
those are informative OPUS parameters):

Regarding the Firefox issue, my guess is the following:

- When Firefox receives the initial SDP offer it places PT 111 as a
receiving opus codec.

- Later when Firefox adds its own audio track and renegotiates, it
adds a *new* PT (109) for its new audio track.

- Probably, if the initial SDP used 109 for opus (rather than 111)
Firefox would not duplicate the codec payload in its re-offer.

-- 
Iñaki Baz Castillo
<[email-masked]>