Weird error: Failed to push down transport description: Failed to set ssl role for the channel

[Yanis Kross]

I'm getting this error:

"Failed to set remote answer sdp: Failed to push down transport description: Failed to set ssl role for the channel"

I have user A and B, user A makes a VIDEO call(offer) to user B and everything works fine. Next user B decides to share his AUDIO and renegotiates making an offer to user A, when B gets the answer from A I have this problem.

A:makesOffer->B:setRemoteDescription:makesAnswer->A:setRemoteDescription

B:makesOffer->A:setRemoteDescription:makesAnswer->B:setRemoteDescription  ->  "Failed to set remote answer sdp: Failed to push down transport description: Failed to set ssl role for the channel"

I've put some emphasis on audio and video because if B decides to share his video instead of his audio everything works as normal.

[Philipp Hancke]

sounds familiar... https://code.google.com/p/webrtc/issues/detail?id=2782

To workaround: make sure your offer/answer role does not change. If user A does a SLD with type=offer initially, it must do that during  the whole session. Which gets ugly...

--

---
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/80627fdc-71fc-492b-8515-ea6d63c81706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yanis Kross]

Thanks. I will try it as soon as I can. It doesn't make much sense though, that means that if I add a stream to a connection I will then need to check if I'm the one who made the offer and if not I need to notify the other peer that I want him to make me another offer because I added a stream. It's annoying to say the least, do you know the reason for it being like this?

[Brian Baldino]

A workaround to avoid asking the peer to send you a new offer is that you could cache the most recent offer you've received, and re-apply it whenever you want to create a new answer.

On Wed, Sep 23, 2015 at 4:53 AM, Yanis Kross <yanis...@gmail.com> wrote:

Thanks. I will try it as soon as I can. It doesn't make much sense though, that means that if I add a stream to a connection I will then need to check if I'm the one who made the offer and if not I need to notify the other peer that I want him to make me another offer because I added a stream. It's annoying to say the least, do you know the reason for it being like this?

--

---
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/5fa7e317-055c-4d9b-aa04-3707eb753d06%40googlegroups.com.

[Arfan Khalil Mughal]

https://code.google.com/p/webrtc/issues/detail?id=2316#c27

[Yanis Kross]

Thanks for the help.

I have another question, knowing that the offerer must always be the offerer and vice versa, is that a quirk from chrome or is it written in the spec somewhere? I don't seem to find it in the spec. It just makes more sense to me that when "onnegotiationneeded" is fired I would make an offer with all my new "state" independently of me being the caller or the callee. 

[Justin Uberti]

That bug is about something else; we don't support DTLS role changes.

You can certainly change who is offerer and answerer though; we do this all the time.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAJraKYitejakj5DSSyfYY0J4rU3bvyPrGiurYqBHm_wstLhMwg%40mail.gmail.com.