Re: DTLS 1.1 failure when Firefox 51 is initiating a call

[ushunmugan]

Thanks!  I suppose that it's too late for Firefox 52, which is beta now.

BTW, I've already verified the fix on developer (53.0a2) and Nightly (54) 
versions.

___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: DTLS 1.1 failure when Firefox 51 is initiating a call

[ushunmugan]

@Martin Thomson  Thank you for the info.  Do you know which version of Firefox 
this fix will land on?

@Prerak Jain  Thank you.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: DTLS 1.1 failure when Firefox 51 is initiating a call

[ushunmugan]

Thanks, Nils.  I captured the DTLS message exchanges for the working and 
failing cases using Wireshark.  I mainly see two differences.
1. In the working case (Firefox 50.1.0), I see a "Server Hello Done" message 
from Firefox first, before a "Server Hello" along with Certificate, Server Key 
Exchange, and Certificate Request records in the same message. 
In the failing case, the Server Hello Done is sent at the end in the same 
message, after Certificate Request (which actually makes more sense?).

2. In the working case, the cipher suite used is: 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013), compared with 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) in the failing case.

It's more likely that the 2nd difference is causing the issue.  I see that this 
and other ECDSA ciphers listed in the Client Hello in both cases. I tried 
disabling ECDSA in the gateway using the cipher list "DEFAULT:!aECDSA:!ECDSA" 
in SSL_CTX_set_cipher_list(), but to no avail - I still see the ECDSA ciphers 
in the Client Hello.

Nils, I'll send you the pcap files for these two cases too.

Please let me know if you have any suggestions.

Cheers,
 Uma

___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

DTLS 1.1 failure when Firefox 51 is initiating a call

[ushunmugan]

Hi, I am encountering a WebRTC DTLS issue with Firefox 51 and our WebRTC 
gateway, which didn't happen with the previous version 50.  This only happens 
when Firefox initiates the call (it works fine when the gateway initiates the 
call).  The gateway, after exchanging the Client/Server Hello messages, is 
trying to read the server certificate, when it gets an "internal error" from 
OpenSSL (version 1.0.1g is being used).  This results in a fatal alert to be 
sent back to Firefox.

I went through the release notes at 
https://developer.mozilla.org/en-US/Firefox/Releases/51, but I didn't see any 
relevant changes.  Does anyone have any idea what could be happening in this 
case?  Any pointers will be appreciated.

Thanks!
 Uma
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added

[ushunmugan]

It works for me when caller is on Chrome (m34) and Callee is on Firefox (v30 
beta), and I have an WebRTC gateway in between.  The things to look for are:
1. The offer should set OfferToReceiveVideo to true, resulting in an SDP with 
a=recvonly for video.
2. The answer SDP should have a=sendonly for video.
3. The onaddstream() should fire on Chrome, and in the handler, you should 
[re]attach the stream to the remote view video element (as when 
setRemoteDescription success callback happens, the remote stream might or might 
not be available).
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added

[ushunmugan]

Given, RTCPeerConnection object is pc, you could get the remote stream as 
follows:  pc.getRemoteStreams()[0].  I suppose that there is a chance this 
value could be null if the stream isn't available.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added

[ushunmugan]

Martin - I think you are talking about bug #998546.  In my asymmetric call 
case, however, onaddstream never fires.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added

[ushunmugan]

I think this is not the correct behavior, given that the remote/answer SDP has 
video disabled (or set to recvonly).

I have a slightly different problem, perhaps with the same underlying cause, 
where an asymmetric call is made between two FF instances. If the caller has 
both audio and video, and callee has only audio in their respective local 
stream, and an offer is made with both OfferToReceiveAudio/Video set to true, 
then the onaddstream is not fired on caller side after setRemoteDescription is 
called with the answer SDP (which correctly has a=recvonly for the video 
m-line). The remote audio wouldn't be played on the caller, as the app wouldn't 
attach the remote stream to the video element in this case.

I use a workaround for this issue, however - on setRemoteDescription success 
callback, I still get and attach the remote stream to the video element, and 
audio is played fine.

Thanks,
 Uma
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media