Re: DTLS 1.1 failure when Firefox 51 is initiating a call
Hi Uma, > On Jan 27, 2017, at 15:42, ushunmu...@gmail.com wrote: > > 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. I’m not aware of any changes in regards to DTLS in the WebRTC implementation of Firefox. Our crypto library NSS might have changed. I would recommend to take a Wireshark trace of the working and the failing scenario and compare the two. Feel free to send me copies of the two files and I’ll have a look as well. Best Nils Ohlmeier signature.asc Description: Message signed with OpenPGP ___ 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
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: Firefox not accepting SDPs for H264 that contain profile-level-id 420029
On Friday, January 27, 2017 at 3:27:15 PM UTC+1, an...@huge.geek.nz wrote: > Hi, > > I've been struggling with using WebRTC together with Janus. > > I have an h264 camera that I can't alter the configuration for. > > The profile-level-id seems to be 420029, which means: > profile is baseline (42 hex = 66 dec = baseline) > constraints 0 > level-idc is 4.1 > > ICE never completes because I suspect FF just barfs on this for some reason, > and I couldn't, no matter how much debug I enabled, find where or why > specifically. > > Chrome works perfectly, but not before offering back profile-id 42e01f (which > the main difference is level-idc is 3.1 instead of 4.1). > > When I re-encoded the content using FFMPEG using an intermediate device, > setting exactly 42e01f then FF finished ICE and played the video (although > this is not a valid solution for my purposes) > > Ideally I want to understand why FF (openh264) can't play 420029, since it > should be baseline, and if there is a fix. > > One more important note: if I took a small clip of the stream to a .mp4 file > (no transcoding), and embed that in HTML5 video tag, FF plays it perfectly. > So the codec SHOULD work as is, but not it doesn't when it's coming over > webrtc. > > Very annoying! Hi all, I managed to "fix" this by rewriting the profile-level-id from 42009 to 42e01f before handing the SDP to FF. I agree it is a hack, but as FF clearly works with this, then why don't you allow 42009? Much more detail on the Janus google group: https://groups.google.com/forum/#!topic/meetecho-janus/jKg5u9421kM ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Firefox not accepting SDPs for H264 that contain profile-level-id 420029
Hi, I've been struggling with using WebRTC together with Janus. I have an h264 camera that I can't alter the configuration for. The profile-level-id seems to be 420029, which means: profile is baseline (42 hex = 66 dec = baseline) constraints 0 level-idc is 4.1 ICE never completes because I suspect FF just barfs on this for some reason, and I couldn't, no matter how much debug I enabled, find where or why specifically. Chrome works perfectly, but not before offering back profile-id 42e01f (which the main difference is level-idc is 3.1 instead of 4.1). When I re-encoded the content using FFMPEG using an intermediate device, setting exactly 42e01f then FF finished ICE and played the video (although this is not a valid solution for my purposes) Ideally I want to understand why FF (openh264) can't play 420029, since it should be baseline, and if there is a fix. One more important note: if I took a small clip of the stream to a .mp4 file (no transcoding), and embed that in HTML5 video tag, FF plays it perfectly. So the codec SHOULD work as is, but not it doesn't when it's coming over webrtc. Very annoying! ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
