Open Bug 1384064 Opened 5 years ago Updated 1 year ago
Firefox doesn't respect a=extmap mapping when renegotiating with create
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.
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.
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
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.
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Type: enhancement → defect
Priority: P3 → P2
You need to log in before you can comment on or make changes to this bug.