DTLS and SDP renegotiation

[ebu...@cafex.com]

I'm trying to add support for DTLS to our product using the bouncy castle library and although I have it working for both Chrome initiated and received calls (so DTLS server and client implementations), I'm having a problem during renegotiation.

If the renegotiation results in the original offerer being the new offerer then all is fine some of the time; unfortunately, when the other side reoffers then whatever the setup field in the SDP is set to, the call no longer works with either decryption failures or a role reversal problem being reported in the log. What exactly happens seems to be random and not too dependant on the setup parameter, sometimes the only hint is Chrome's log mentioning that something to do with NSS has reset stuff (I can't remember the exact message,and it doesn't want to happen at the moment), other times it complains about not being able to change role and setting the remote description fails.

I know there was supposed to be a problem with M30, but I'm trying this with M33 and dev 34. Are there still known issues (I can't find a reference to any), or is this something new, or can anyone suggest how I can get it to stick to one role (I've tried always giving setup:active in any SDP we give to Chrome outside the original offer, and the same with setup:passive and actpass, nothing seems to work except for sometimes one renegotiation).

I'm going to try get it working with Firefox shortly to see if it works there.

Eric

--------------------

Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  CafeX Communications.

[Justin Uberti]

Chrome doesn't support role reversal at this time. Once the active/passive roles are determined, the respective ends need to continue using those roles (which is done automatically for Chrome-Chrome calls).

--
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[ebu...@cafex.com]

The problem is that Chrome either errors or doesn't do anything. I have to put actpass in any offers (Chrome errors otherwise), so I can't say what role I am there, but if I presume I'm a client like I was to start with then Chrome ignores the new hellos, and it doesn't send any new ones (and decryption ceases to work pretty much as soon as Chrome has produced an answer). If I got it to produce a new offer and put either active or passive in the answer then the most I get is an encrypted alert, presumably meaning the connection needs re-handshaking.

Can anyone point me to a demo where renegotiation is used so I can see exactly what Chrome is doing?

Thanks.

Eric

[Justin Uberti]

You can probably update pc1.html to do 2 offer/answer sequences pretty easily.