Failed to set remote answer sdp: Failed to push down transport description: Failed to set SSL role f

[Son Le]

I'm using webRTC to build a system which supports audio calls. Here's how it works:  

- User A `createOffer`, then `setLocalDescription` with the `offer`  

- User B `receiveOffer`, then `setRemoteDescription` with the `offer`  

- User B `createAnswer`, then `setLocalDescription` with the `answer`  

- User A `receiveAnswer`, then `setRemoteDescription` with the `answer`  

The problem is that, after A received answer from B, when A does `setRemoteDescription(answer)`, this error appears: 

**Uncaught (in promise) DOMException: Failed to set remote answer sdp: Failed to push down transport description: Failed to set SSL role for the channel.**  

I have no clue why this error appears. I tried googling it but no luck so far. Any help would be appreciated !

[Taylor Brandstetter]

Can you attach the offer/answer SDP?

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/dc96fe63-097f-4035-a686-de44affab6ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Son Le]

Hi Taylor, thanks for replying me ! What do you mean by attaching the offer/answer SDP ? And do you know what is the meaning of the error "Failed to set SSL role for the channel" ? I have no clue what it means which makes it harder for me to debug.

On Thursday, July 6, 2017 at 10:56:06 PM UTC+7, Taylor Brandstetter wrote:

Can you attach the offer/answer SDP?

On Wed, Jul 5, 2017 at 10:36 AM, Son Le <sonl...@gmail.com> wrote:

I'm using webRTC to build a system which supports audio calls. Here's how it works:  

- User A `createOffer`, then `setLocalDescription` with the `offer`  

- User B `receiveOffer`, then `setRemoteDescription` with the `offer`  

- User B `createAnswer`, then `setLocalDescription` with the `answer`  

- User A `receiveAnswer`, then `setRemoteDescription` with the `answer`  

The problem is that, after A received answer from B, when A does `setRemoteDescription(answer)`, this error appears: 

**Uncaught (in promise) DOMException: Failed to set remote answer sdp: Failed to push down transport description: Failed to set SSL role for the channel.**  

I have no clue why this error appears. I tried googling it but no luck so far. Any help would be appreciated !

--

---
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.

[Taylor Brandstetter]

Sorry, I mean share the "offer"s and "answer"s that get passed into `setLocalDescription` and `setRemoteDescription` leading up to this error. The easiest way is probably to just generate a "chrome://webrtc-internals" dump.

The SSL role corresponds to the "a=setup" attribute in SDP. So this error would occur if, for example, you applied a remote answer with "a=setup:active", establishing the remote endpoint as the SSL client, but then applied a new remote offer with "a=setup:passive", changing the role without also changing the fingerprint (which is the only way we currently support forming new DTLS associations).

Or, maybe something else is going on. If so, having the SDP would let me reproduce the issue and debug it.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/088a90b8-1452-4e86-9a2b-1d3a8b9485d6%40googlegroups.com.

[Son Le]

@Taylor thanks ! Here I generated the webrtc_internals_dump file right after the error occurs: https://gist.github.com/sonlexqt/bf45f067aa7242ee44dec8843b839987. 

I want to give more details about this case:

- First of all user A and B connect with each other for sending text messages via RTCDataChannel (everything works fine)

- Then, user A wants to call user B (audio call): user A get his user media (navigator.mediaDevices.getUserMedia) => addStream => create a new offer. User B get the offer => get his user media => addStream => create a new answer...

By looking at the webrtc_internals_dump file, I notice that in the first setRemoteDescription it said "a=setup:actpass" but it the last setRemoteDescription it said "a=setup:active" (right before the SSL role error).

Again, thanks so much and I'm looking to hearing from you !

[Nils Ohlmeier]

Hi Son,

I think you are facing this bug in Firefox regarding not changing setup roles https://bugzilla.mozilla.org/show_bug.cgi?id=1329028

Best

  Nils

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/dab915ff-b81b-4bc2-9170-f6a5b24b5c5e%40googlegroups.com.

[Son Le]

Hi Nils, thanks so much ! You're right the bug only happens when I do a Chrome - Firefox test (one user uses Chrome and the other uses Firefox). 

Is this a bug on Firefox ? Is there any possible workaround for this ? 

By the way, what's the use of the attached signature.asc file ? (sorry if there're silly questions)

[Taylor Brandstetter]

It does seem to be a Firefox bug. In summary, what's happening is:

1. Firefox offers "actpass"
2. Chrome answers "active". This establishes Chrome as the DTLS client, and Firefox as the DTLS server.
3. Chrome re-offers, with "actpass" (because that's what the spec says, or at least how we interpreted it for a long time)
4. Firefox offers with "active", but with the same DTLS fingerprint. Chrome doesn't like this; it's interpreted as an attempt to change the DTLS role from "server" to "client" without creating a new association.

To work around this, you could:

• Detect when this occurs and change the DTLS role from "active" to "passive" before passing the SDP into setRemoteDescription. 
• Ensure that the offer/answer direction remains consistent. Meaning, if Firefox generates the initial offer, it generates all subsequent offers as well. I'm not sure how common this practice is, but it probably would avoid a lot of interop bugs.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/61d8e946-b5e6-4f06-91df-9e1f1841349d%40googlegroups.com.

[Son Le]

Hi Taylor ! Yes at the moment in my app, it ensures the offer/answer direction remains consistent (only the "talker" can create offers to the "listener").

Did you mean is that in step 4, we should modify the DTLS role from 'active' to 'actpass' ? I'm not sure how we can modify the DTLS role using javascript ?

[Taylor Brandstetter]

Hi Taylor ! Yes at the moment in my app, it ensures the offer/answer direction remains consistent (only the "talker" can create offers to the "listener").

That's not what I see from the internals dump, though; the first offer/answer is Firefox -> Chrome, and the second is Chrome -> Firefox.

 Did you mean is that in step 4, we should modify the DTLS role from 'active' to 'actpass' ? I'm not sure how we can modify the DTLS role using javascript ?

From "active" to "passive", actually. You may be able to get away with doing something simple, like:

if (remote_endpoint_passive) {

  answer.sdp = answer.sdp.replace("a=setup:active", "a=setup:passive");

}

There are also SDP parsing/serialization libraries written in JS, though I haven't used them enough to have a specific recommendation.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/061706a3-bddf-4941-bb2e-c31db7d63230%40googlegroups.com.

[Son Le]

Thanks Taylor ! I took a carefully look and you're right. 

For the initial offer, the offerer is randomly assigned. I modified my code so that in ensures the offer/answer direction remains consistent. Now it works ! 

Thanks a lot for your help :)

[Basar Daldal]

I have some questions around the same topic: What is the easiest / recommended way to handle role conflicts? Which of the below are valid options?

1. When A and B are in a call, where A is the initial offerer (actpass) and B is the answerer (active), when B makes an a re-offer, can / it do the offer as a=active because it is already assigned this role? Or similarly if A is going to do a re-offer, can it do as a=passive?  The reason is we already know that role change is not possible during mid call events and those two endpoints have already roles assigned to them. Doing the re-offer as "actpass" is giving the remote end the chance to make a choice. Certainly, if the remote end is same, it will still select the same role but the problem starts when the remote party is a different endpoint like a media server (playing announcement) or the re-offer results with a transfer to a new endpoint.

 

I read in another thread that Chrome does not allow offers to be made as active or passive, it always mandates "actpass" which is actually a road blocker for this option. Is this true?

2. It is told that a change of fingerprint may allow role change. How does it work? Suppose A makes an offer and B answers with an unexpected role which will result with WebRTC engine giving error during setRemoteDescription. What is A assumed to do here before calling setRemoteDescription?

3. if A simply alters the role coming from remote end before calling setRemoteDescription, it will not get an error but the role of B is known to be different at each endpoint with that change, B thinks it is passive where A thinks it is active. How can this work?

4. Would opening a new peer connection and doing renegotiation be a valid option?

Thanks,

Basar

[Taylor Brandstetter]

when B makes an a re-offer, can / it do the offer as a=active because it is already assigned this role?

Yes, and Chrome should accept this now.

Certainly, if the remote end is same, it will still select the same role but the problem starts when the remote party is a different endpoint like a media server (playing announcement) or the re-offer results with a transfer to a new endpoint.

Correct. In theory this should be supported, but it's still only possible if the offer initiates an ICE restart, because otherwise the endpoint doesn't have a way of telling what packets are for what DLTS association.

2. It is told that a change of fingerprint may allow role change. How does it work? Suppose A makes an offer and B answers with an unexpected role which will result with WebRTC engine giving error during setRemoteDescription. What is A assumed to do here before calling setRemoteDescription?

As mentioned above, A would have been required to do an ICE restart. But Chrome still doesn't support this. We currently only support the offerer initiating a new DTLS association.

3. if A simply alters the role coming from remote end before calling setRemoteDescription, it will not get an error but the role of B is known to be different at each endpoint with that change, B thinks it is passive where A thinks it is active. How can this work?

In this case, I don't think Firefox actually ends up using the active role, it just puts that in the SDP. Though I don't know the details of the bug.

 4. Would opening a new peer connection and doing renegotiation be a valid option?

I suppose, depending on how it impacts the user... But I hope it doesn't have to come to that. I'd recommend the SDP munging approach (#3) until the bug is fixed.

 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/818b7b36-89e7-46cb-ac97-7e2751625885%40googlegroups.com.