1384064 - Firefox doesn't respect a=extmap mapping when renegotiating with createOffer()

Status: NEW

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

Description

[Iñaki Baz Castillo]

The mapping of RTP header extensions should not be modified once in a multimedia session, meaning that future new calls to pc.createOffer() should not change the previous mapping. But Firefox fails on this.

Steps to reproduce it:

- Open https://jsfiddle.net/ibcaliax/uan2fove/ with Firefox.
- Open the devtool console.

There we can see that the given SDP is set as remote description, producing a local answer with the following a=extmap mapping:

a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

This is OK since it matches a subset of the mapping in the initial remote offer.

Later, when calling pc.createOffer(), the resulting SDP re-offer has the following a=extmap mapping:

a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

To be perfectly clear, it's not so important the fact that Firefox adds a new a=extmap during a renegotiation, but the fact that it does not even keep the already negotiated a=extmap mapping values.

NOTE: This works properly in Chrome.

NOTE: This may be (or may be not) related to bug 1247725 (which is just about PT values and doesn't seem to be a real implementation bug).

NOTE: It may happen that, according to some spec, it's valid to introduce a duplicated a=extmap mapping in a re-offer or replace its mapping. However, even if that is true, both bug 1247725 and this one produce an inconsistent and unexpectable behavior and IMHO Firefox should evolve to behave like Chrome in this case, because that's the behavior that really makes sense.

Comment 1

[Byron Campen [:bwc]]

While it may make sense to do this, is there any spec language that says you cannot renegotiate extmap values? I'm not seeing any in the base spec, or in jsep.

Comment 2

[Iñaki Baz Castillo]

I couldn't find any spec stating that.

Mail thread open in rtcweb WG: https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=rtatigxbppCOU56MiXs53DCneM4

Comment 3

[Iñaki Baz Castillo]

Please, read the thread in the rtcweb WG. Taylor found a text in RFC 5285:

> Identifiers values in the valid range MUST NOT be altered (remapped).

Yes, I know that in my above example this does not happen, but I expect that Firefox is not considering that, and that Firefox would remap them anyway to setup its hardcoded default ext mappings.

Comment 4

[Bulk Bug Changes for mreavy's org]

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

Comment 5

[stapatrick9]

from https://tools.ietf.org/html/rfc8285#section-5

Local identifiers in the valid range inclusive in an offer or answer
must not be used more than once per media section (including the
session-level section). The local identifiers MUST be unique in an
RTP session, and the same identifier MUST be used for the same
offered extension in the answer. A session update MAY change the
direction qualifiers of extensions being used. A session update MAY
add or remove extension(s). Identifier values in the valid range
MUST NOT be altered (remapped).

Note where is says "Identifier values in the valid range
MUST NOT be altered (remapped)."
I would think they would stay the same when you were renegotiating because they can already been set on the local description.
Chrome already does this.

This is causes problems for us because the answerer expects the header extensions ids to stay the same.

I set this as localdescription in CHROME:

m=audio 9 UDP/TLS/RTP/SAVPF 96 9 0 8 97 98
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 9 UDP/TLS/RTP/SAVPF 99 100 101
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid

when I created an offer I got:

m=audio 57387 UDP/TLS/RTP/SAVPF 96 9 0 8 97 98 103 104 106 105 13 112 113
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:14 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
m=video 9 UDP/TLS/RTP/SAVPF 99 100 101 123 122 127 121 102 120 126 119 107 108 109 110 111 125 118 114 115 116
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:13 urn:ietf:params:rtp-hdrext:toffset
a=extmap:12 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:10 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

Observe that the id for the extension remained the same

But in FIREFOX when this is set in the local description the
m=video 9 UDP/TLS/RTP/SAVPF 99 100 101
c=IN IP4 0.0.0.0
a=extmap:1/recvonly http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2/sendrecv urn:ietf:params:rtp-hdrext:sdes:mid

andd I create an offer I get:
m=audio 57423 UDP/TLS/RTP/SAVPF 96 9 0 8 98
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 9 UDP/TLS/RTP/SAVPF 99 100 101 97 98
c=IN IP4 0.0.0.0
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

Note the header extension for urn:ietf:params:rtp-hdrext:sdes:mid changed from 2 to 3.

Comment 6

[Nils Ohlmeier [:drno]]

If I'm not mistaken Inaki's old fiddle (Thanks for that!) no longer repros a problem. Firefox does answer with the IDs from the offer now.

But based on comment #5 the problem still exists when the IDs cross multiple m-sections.