M97 changes of extmap values cause call failures

[meron.elpaz rbbn]

Our WebRTC solution started to face critical errors when our clients browsers updated to Chrome M97. It seems that M97 WebRTC changed the extmap values mapping in a way that it is not backward compatible. This affects part of our call scenarios which are slow start based (late offer).

 

The errors happen when one side is using M97 and the other side is using a lower chrome version or a Firefox browser.

Due to the mismatch of extmap values between the different chrome versions, when a re-invite occurs one of the sides is failing upon setting local/remote description (depends on which side initiate the offer)

 

An example of a change that breaks our solution is:

M96:

a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

M97:

a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

 

1. First, I don’t see any PSA for M97 release notes, last one available is only M96 - https://groups.google.com/g/discuss-webrtc/c/Bp8OzBzipSc/m/0AC4OGhdAgAJ
2. Are the changes for extmap mapping intentional? Can they be reverted to match M96 and below?

 

For reference, I’m attaching the following SDPs just before setting local/remote description on my client using M97, remote client is M96.

Once client is setting the re-invite answer remote description, the following error is received:

Failed to process answer: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Failed to set remote video description send parameters for m-section with mid='1'. 

Note, if I remove the following extmap from the SDPs the scenario is successful

'playout-delay',
'sdes:rtp-stream-id',
'video-content-type',
'repaired-rtp-stream-id'

 

Thanks,

Meron

[Philipp Hancke]

like in https://bugs.chromium.org/p/webrtc/issues/detail?id=13564 your offer seems to violate the requirement that when using BUNDLE, the extmap ids must be the same for all bundled sections.

You'll need to fix your server.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/f210eab5-3a32-428f-9449-a52bb9fbd8d5n%40googlegroups.com.

[meron.elpaz rbbn]

Thank you Philipp for your reply.

reading into the the bug details you pointed to, I believe our issue is different than the description.

bug issue - Bundling several mid lines, where each of them defines the same value extmap line to different attributes, specifically:

a=mid:1
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
...
a=mid:3
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

that is a clear issue, I agree.

in our SDP examples there is no such missmatch, the extmap assignments are consistent between the mid lines.

Our issue is simply that in a slow-start SDP exchange, the fact that M96 and M97 by default maps in the offer similar attributes to different values break backward compatibility and fails to set description. for example:

M96 will map extmap:5 to - urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

But M97 will map extmap:5 to - http://www.webrtc.org/experiments/rtp-hdrext/playout-delay

Please advise and thank you for the attention

[Philipp Hancke]

ah, your problem is that the id attribute of extensions changed?

These ids (like codec ids) do not have *any* stability guaranteed and they can change any time.

The dynamic assignment changed indeed since M97 no longer announces the RID or RRID extension for audio (https://bugs.chromium.org/p/webrtc/issues/detail?id=13279 which sadly did not show up in the release notes published yesterday)

This means the ids 5 and 6 were no longer used and did not have to be remapped which is what previously happened.

That is working as intended.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/af7010b5-331f-45ae-93ac-77d37eb96300n%40googlegroups.com.

[Uma Maheswar]

I still did not get how to fix this issue. I am using one client which is having chromium version 102 and other client which is having version 91. During initial call establishment "a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01" is negotiated. After placing the call on hold and resume, the resume offer is having "a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01" which causing the web rtc stack throw exception -  "stack":"Error: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set local audio description recv parameters for m-section with mid='audio'.."}

Appreciate your valuable suggestion to fix this issue.

Regards,

UmaMaheswar