5

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 !

sonlexqt
  • 6,011
  • 5
  • 42
  • 58

2 Answers2

4

I had this problem when doing renegotiation. I solved this by making sure the server should answer sdp setup as passive. Usually this error on chrome <-> firefox.

You can also check here: https://bugs.chromium.org/p/webrtc/issues/detail?id=2782

firefly28
  • 119
  • 1
  • 4
3

It does seem to be a Firefox bug.
In summary, what's happening is:
- Firefox offers actpass
- Chrome answers active. This establishes Chrome as the DTLS client, and Firefox as the DTLS server.
- Chrome re-offers, with active (because that's what the spec says, or at least how we interpreted it for a long time)
- 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, what I did is: 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.
More detailed discussion: https://groups.google.com/forum/#!topic/discuss-webrtc/gsw3OEAwNKo

sonlexqt
  • 6,011
  • 5
  • 42
  • 58