1268533 - ICE restart is falsely detected on some WebRTC renegotiation scenarios

Status: NEW

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

Description

[ushunmugan]

Attachment: Firefox_console_false_ICE_restart.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Steps to reproduce:

1. A new WebRTC call arrives (from a gateway) with "a=group:BUNDLE" and audio and video m-lines in the offer SDP, and yet different ICE credentials for the two media types (in case bundle isn't supported).  Say video is recvonly, though it shouldn't matter.
2. Firefox accepts the offer and responds with bundle support indicated, and audio and video accepted.
3. Firefox receives a new offer, say with full-duplex video, but this time the ICE credentials are the same for audio and video m-lines, given media bundle is in use.



Actual results:

Firefox triggers the error callback on calling setRemoteDescription with the new remote SDP, and the following is the error text:

ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd)ice-ufrag (old): em5Qice-ufrag (new): mzGDice-pwd (old): rwszxa+y3bVK4qp7x+tF66ice-pwd (new): rn8UUuGL20FiUsSQ5O+ljX


Expected results:

Since bundle is being used, the ICE credentials for the video should not be needed or used, and could be the same as the ones for audio.  So, the change in values for ice-ufrag and ice-pwd in the video m-line of the new SDP should not be treated as an ICE restart.

Comment 1

[Byron Campen [:bwc]]

Try nightly, we've landed ICE restart support. Not sure if it will work (this might still be detected as a partial ICE restart, which we do not yet support), but is worth a try.

Comment 2

[ushunmugan]

I tried with latest nightly (49.0a1) today.  The error has changed, but setRemoteDescription still failed: "InvalidSessionDescriptionError: Partial ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd on fewer than all msections)".

I suppose it shouldn't be hard to fix this - just don't do the ICE restart check on the 2nd m-line when bundle is being used?

Comment 3

[Byron Campen [:bwc]]

Yeah, that's what I was afraid of. We'll need to teach that code to grab the ICE ufrag/pwd from the master bundle msection on each SDP and compare them, although there may be some wrinkles with remote offers and SDP rewriting of answers (for instance, the reoffer has different credentials for bundled msections in case bundle is rejected, which we will ignore since we like bundle, but then content rewrites to not use bundle).

Comment 4

[Maire Reavy [:mreavy]]

Byron -- I've confirmed this bug.  How soon do we need to fix this?  What priority should it get?  What versions are affected?

Comment 5

[Byron Campen [:bwc]]

I'm pretty sure this has existed since renegotiation landed. It is a relatively rare scenario, but I don't think it will be hard to fix. Maybe a P3?

Comment 6

[ushunmugan]

Thank you guys for the prompt analysis/response.  It is not a rare scenario with our gateway - if a call comes into the Firefox/WebRTC app (note, if the WebRTC app initiates the call, then it's OK), and then a renegotiation happens, say due to a hold request, then this issue would cause the call to drop.  

FYI, we are working around it now by using a offer-bundle-only option in the gateway (so that the gateway assumes bundle support, and use the same ICE credentials for all m-lines in an initial offer sent out).

Comment 7

[vance]

Hi, guys!

What is the state of the issue in this thread?
We encountered the same error in following case:

- Firefox receives a call with audio+video
- remote side turn the video off (video with a=inactive, and without ICE candidate received), audio is still working
- remote side turn the video back on - Firefox receives SDP with audio (old ICE) and video (new ice-ufrag, ice-pwd)
- as a result Firefox fails to set it with error:
 "Partial ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd on fewer than all msections)"

Any estimates when the issue may be fixed?

Thanks in advance for your help!

Comment 8

[Bulk Bug Changes for mreavy's org]

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

Comment 9

[vance]

Hi, community!

The issue is still valid for us and is blocking to use complete functionality of our webrtc implementation in Firefox.

Can someone tell, what are the plans regarding the task, and if possible some estimates (going to be done next month/year... going to be closed?)

thanks in advance!

Comment 10

[Archana]

Any estimate when the issue may be fixed?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.