UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36

Steps to reproduce the problem:
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.

A WebRTC endpoint must be able to introduce new PT values in a SDP re-offer. RFC 3264:

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.

Also, let's take into account that, theoretically Chrome guarantees that if createAnswer() works, calling to setLocalDescription() with the generated answer must also work, which is NOT the case.

What is the expected behavior?
Chrome should accept its own generated SDP answer.

What went wrong?
It didn't.

Did this work before? No 

Chrome version: 53.0.2785.89  Channel: beta
OS Version: OS X 10.11.5
Flash Version: Shockwave Flash 22.0 r0

Also reported in rtcweb WG: https://mailarchive.ietf.org/arch/msg/rtcweb/CF-bGveuUOlMWTyuVlWv2Ul1UO0