Web RTC Renegotiation Errors

Question

I've set up a WebRTC application that works as follows: (Beginning at step 5, I stop using CALLER/CALLEE because either the CALLER or the CALLEE can initiate the stream)

1. CALLER creates peer connection with only a data channel, creates offer, sets local description, and sends offer to CALLEE.
2. CALLEE sets remote description, creates answer, sets local description, and sends answer to CALLER.
3. CALLER sets remote description.
4. CALLER and CALLEE can successfully communicate over the data channel.
5. PEERA adds an audio and/or video stream to peer connection.
6. PEERA's onnegotiationneeded event fires.
7. PEERA creates offer, sets local description, and sends offer to PEERB.
8. PEERB receives offer, sets remote description, creates answer, sets local description, and sends answer to PEERA.

If PEERA and PEERB are both using Chrome: If PEERA is the CALLER, then everything behaves normally, and the stream is received successfully by PEERB. If PEERA is the CALLEE, then PEERB blows up in step 8 when setting the LOCAL description. The stream is received by PEERB, but displays only as a black box when sent to a <video> element.

The error logged is:

Failed to set local answer sdp: Failed to push down transport description: Failed to set SSL role for the channel.

When both PEERA and PEERB are using FireFox: PEERA can be either the CALLER or CALLEE, and everything behaves normally, and the stream is received successfully by PEERB.

When the CALLEE is using Firefox and the CALLER is using Chrome: PEERA can be either the CALLER(Chrome) or CALLEE(Firefox), and everything behaves normally, and the stream is received successfully by PEERB.

When the CALLEE is using Chrome and the CALLER is using Firefox: If PEERA is the CALLER(FireFox), then everything behaves normally, and the stream is received successfully by PEERB(Chrome). If PEERA is the CALLEE(Chrome), then PEERB(FireFox) blows up in step 8, when setting the REMOTE description.

The error logged is:

DOMException [InvalidSessionDescriptionError: "ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd)ice-ufrag (old): a59T34ixyZjsTUuJice-ufrag (new): rsCN1ugVKHJQzmMbice-pwd (old): KqOHtqdzFp6VwG+3hxbjcQFcice-pwd (new): uVvowvgsKIwuCq/bDmcGbSPA" code: 0 nsresult: 0x0]

Answer 1

Chrome<->Chrome renegotiation

The error you get when PEERA is the callee in the renegotiation is typically due to Chrome changing the DTLS role, however I am not able to reproduce your problem. I believe that this JSFiddle link illustrates the scenario you are describing, and I am able to successfully renegotiate the call using Chrome 47.

If you can still reproduce the problem, take a look at the a=setup: bits of the SDP that are generated in the offer/answer, and compare them to the initial offer/answer. If I'm right, you'll see that to begin with, CALLER will have a=setup:actpass in the offer, and CALLEE will have a=setup:active in the answer. This means that the CALLER is now playing the 'passive' DTLS role and the CALLEE is playing the 'active' DTLS role.

Then when you initiate a renegotiation, PEERA is more than likely sending a=setup:actpass. PEERB, which should send a=setup:passive, is sending a=setup:active instead, which essentially causes a DTLS role swap. The error is due to the fact that Chrome does not support DTLS role changing for peer connections.

There is an open ticket on the google chrome bug tracker related to this, where I have posted a reproduction of the issue you're describing using a different scenario: starting a video-only call and the callee renegotiating to add video+audio.

The only solution that I know of at this time is to "munge" (alter) the SDP prior to calling setLocalDescription, so that it has the values that you want. So, for example, if you are about to process an answer and you know you are the passive DTLS role, you can do like

answer.sdp = answer.sdp.replace('a=setup:active','a=setup:passive');
pc.setLocalDescription(answer).then(...);

Firefox<->Firefox renegotiation

Yep, everything works great! That's because Firefox "does the right thing" with the DTLS roles when renegotiating in all the tests I've run. Take a look at the difference between these SDPs and the Chrome SDPs.

Firefox<->Chrome renegotiation interop

I am able to reproduce the issue you are describing with InvalidSessionDescriptionError showing up in Firefox. I haven't been able to come up with a solution yet nor know the cause at this time.

I'm also having a myriad of other renegotiation interop issues. It's pretty discouraging at the moment.

Please post back if you learn more. Definitely still lots of struggling with renegotiation interop!