1247725 - SDP offer has two payload types referring to the same codec

Status: RESOLVED DUPLICATE of bug 1290948

(Core :: WebRTC: Signaling, defect, P3)

Description

[Taylor Brandstetter]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36

Steps to reproduce:

1. Create peer connections in both Chrome and Firefox.
2. Add a video stream to the Chrome peer connection, and do an offer/answer exchange (initiated by Chrome).
3. Add a video stream to the Firefox peer connection, and do a second offer/answer exchange, this time initiated by Firefox.


Actual results:

At step #2, the Chrome offer uses a payload type of 100 for VP8/90000, which differs from Firefox's default payload type of 120.

Chrome offer (only rtpmap lines):

a=rtpmap:100 VP8/90000
a=rtpmap:101 VP9/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116

Firefox answer: 

a=rtpmap:100 VP8/90000

So far so good. But after adding a stream to the Firefox PC and creating a new offer, it ends up with two payload types (100 and 120) referring to the same codec:

a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=rtpmap:100 VP8/90000

This goes against RFC 4566, which says "Up to one rtpmap attribute can be defined for each media format specified."

This ends up confusing Chrome, which expects to receive payload type 100, when 120 is what's actually sent. See this related bug report: https://bugs.chromium.org/p/webrtc/issues/detail?id=5499&can=2&q=&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Component%20Status%20Owner%20Summary&groupby=&sort=


Expected results:

The Firefox offer only contains one a=rtpmap line for VP8/90000, and video flows bidirectionally with no issues.

Comment 1

[Byron Campen [:bwc]]

I'm pretty sure I know what is causing this. Thinking about the best solution.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

> This goes against RFC 4566, which says "Up to one rtpmap attribute can be defined for each media format specified."

"Media format" refers to a payload type, so a=rtpmap:120 VP8/90000\r\n a=rtpmap:100 VP8/90000 is totally valid SDP.  You just can't have two a=rtpmap:100's in the same m= section.  

Mappings are for payload types, not rtpmaps - you don't say "this is VP8, which payload is that?"  You say "this is PT=100, which codec is that?"

Your snippet of the SDP here and in the chromium bug leaves out some important things, like which payloads were accepted.  Can you provide the full SDP?

This is still silly for us to do, even if it's valid spec-wise.  But if this is breaking (real) interop with Chrome in renegotiation, we may want to bump it higher.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

I commented in the Chrome bug; hta and I agree this is valid, and chrome should answer one of them I believe.  We should try to avoid sending them (reuse existing PT for a codec when renegotiating, though this can get "fun" when dealing with edge-case conflicts, like if we previously agreed H264 was 120 and VP8 was 126).  We should write down the algorithm for selecting PT's on renegotiation offers.

Comment 4

[Taylor Brandstetter]

> Your snippet of the SDP here and in the chromium bug leaves out some
> important things, like which payloads were accepted.  Can you provide the
> full SDP?

Both 100 and 120 (the VP8 payload types) were accepted. This is the crucial point, because Chrome later ends up ignoring one of the payload types. The full SDP is in an attachment on the Chrome bug: https://bugs.chromium.org/p/webrtc/issues/attachmentText?aid=7665

> This is still silly for us to do, even if it's valid spec-wise.  But if this
> is breaking (real) interop with Chrome in renegotiation, we may want to bump
> it higher.

This can be fixed on the Chrome side by only answering with one payload type, as you and others have pointed out. So, since you and hta agree that this is valid spec-wise, I'd say the burden falls more on Chrome to fix this.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

> Both 100 and 120 (the VP8 payload types) were accepted. This is the crucial
> point, because Chrome later ends up ignoring one of the payload types. The
> full SDP is in an attachment on the Chrome bug:
> https://bugs.chromium.org/p/webrtc/issues/attachmentText?aid=7665

Yeah - if they accept both, they had better be ready and willing to receive both/either, and apparently they aren't.

> This can be fixed on the Chrome side by only answering with one payload
> type, as you and others have pointed out. So, since you and hta agree that
> this is valid spec-wise, I'd say the burden falls more on Chrome to fix this.

Yes - though we'll want to fix ours as well to avoid confusing implementations with bugs (like Chrome).

Comment 6

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 7

[Byron Campen [:bwc]]

I just wrote a test-case for this, and it does not appear to happen anymore. I'm reasonably sure it was fixed when we implemented RTCRtpTransceiver (bug 1290948).