Re: Firefox gather candidates for every media track even with max-bundle as bundlePolicy
On Friday, 22 September 2017 06:35:48 UTC+5:30, Nils Ohlmeier wrote: > Hi Prerak, > > > On Sep 21, 2017, at 02:27, prerak jain wrote: > > > > Firefox gathers candidates for every track which is added to the > > PeerConnection object even when bundle policy is set to max-bundle. As per > > the specs, it should only collect candidates for any one of the media track. > > Is there any way I can stop Firefox to gather candidates for all the tracks? > > No we have not invested the time in such optimizations. > Plus even if we gather candidates only for one bundled track, we still would > need to have separate candidates for RTCP in case the other side does not > support rtcp-mux. > > Best regards > Nils Ohlmeier Do you have any plan to implement the ice gathering as per the specs for max bundle policy. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Firefox gather candidates for every media track even with max-bundle as bundlePolicy
Firefox gathers candidates for every track which is added to the PeerConnection object even when bundle policy is set to max-bundle. As per the specs, it should only collect candidates for any one of the media track. Is there any way I can stop Firefox to gather candidates for all the tracks? ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Webrtc Simulcast: FF sending only one stream in simulcast enabled RTP session
On Thursday, 6 July 2017 04:43:01 UTC+5:30, Nils Ohlmeier wrote:
> > On Jul 5, 2017, at 05:28, theashwin...@gmail.com wrote:
> >
> > We are testing FF/Simulcast with our SFU, expecting FF to send RTP of all
> > three streams as advertised in SDP.
> >
> > simulcast parameters
> > {
> >encodings: [{
> >rid: "720",
> >}, {
> >rid: "360",
> >scaleResolutionDownBy: 2,
> >}, {
> >rid: "180",
> >scaleResolutionDownBy: 4,
> >}, ]
> > };
>
> Not sure if it makes a difference, but have you tried to add the maxBitrate
> parameter to the encodings?
> Like here:
> http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62
>
>
>
> >
> > Offer:
> >
> > a=simulcast: send rid=720;360;180
> > a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
> > a=rid:720 send
> > a=rid:360 send
> > a=rid:180 send
> >
> > Answer:
> >
> > a=simulcast: recv rid=720;360;180
> > a=extmap:3/recvonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
> > a=rid:720 recv
> > a=rid:360 recv
> > a=rid:180 recv
> >
> > But when we check the outgoing rtp packet header extension, we can see that
> > it is sending packets for resolution 180p (because the extension is
> > corresponding to rid 180)
> >
> > As per the simulcast, we expect it to send all three streams(720, 360 &
> > 180). Any idea what are we doing wrong here?
>
> Have you looked at all RTP packets?
> I’m asking because I noticed that in Firefox 56 we only include the RID in
> the very first packet for each frame. So you need to carefully search for the
> beginning of the next frame to find the 2nd and 3rd RID.
>
> Best regards
> Nils Ohlmeier
We are able to see all the simulcast streams after using the maxBitrate
parameter as you suggested. But I think it's a bug in Firefox that it doesn't
start the simulcast stream without the maxBitrate being set to the encodings.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Does Firefox support temporal scaling for VP8 ?
Does Firefox support VP8 temporal scaling, if so how can I enable it. ___ 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
On Thursday, 2 February 2017 01:54:23 UTC+5:30, ushun...@gmail.com wrote: > Hi Prerak, > > Thank you much for the info. When I made the client create an RSA P-256 > certificate and use it in PeerConnection (in fact, this is required with > Chrome 52 and later, when using OpenSSL 1.0.1g, for e.g.), it still didn't > work, but the cipher suite used was the same as in the working case. > However, I could see that the ECDH named curve used in Server Key Exchange > was ecdh_x25519 (0x001d) - as you have noted, compared to secp256r1 (0x0017) > in the working case. I also don't see any named curves specified in Client > Hello. Note that secp256r1 is one of the curves supported by Firefox, > according to the code diff you've pointed out. Also note that DTLS works > fine when Firefox receives a call, and acts as a client. > > It looks like that SSL_CTL_set1_curves() is only available from OpenSSL > 1.0.2. FYI, we are already using > EC_KEY_new_by_curve_name(NID_X9_62_prime256v1), followed by > SSL_CTX_set_tmp_ecdh() to set the curve name - this was required a while ago > after Firefox made some changes on this regard. Other than updating OpenSSL, > is there any other way to have the supported named curves listed in the > Client Hello? > > Thank, > Uma I was using the same openssl API you mentioned EC_KEY_new_by_curve_name(NID_X9_62_prime256v1), it works only in case when your server is acting as DTLS server thats why it works when Firefox acts as the DTLS client. This API doesn't add named_curve field in Client Hello message, so had to upgrade openssl to 1.0.2 to unblock WebRTC Firefox calls. So either you can wait for the fix Martin has mentioned or upgrade openssl to at least 1.0.2. ___ 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
On Saturday, 28 January 2017 05:49:38 UTC+5:30, ushun...@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. > > Thanks! > Uma Hi Uma, The issue you are facing is due to the new changes in NSS crypto library update on Firefox 51, where they have made ECDH named curve X25519 as the default curve for DTLS negotiation(https://hg.mozilla.org/mozilla-central/diff/494e0af296f6/media/mtransport/transportlayerdtls.cpp), the openssl version(1.0.1g) you are using does not support X25519 named curve, so if you do not publish any named curve support in Client Hello from your server Firefox will use X25519 to create the DTLS connection and it will fail. To fix it either can update the openssl version on your server to 1.1.1 or use SSL_CTX_set1_curves(https://wiki.openssl.org/index.php/Manual:SSL_CTX_set1_curves(3)) API in your DTLS implementation to set named curves while creating Client Hello (refer the code diff link I mentioned to check the supported named curve list) Thanks Prerak ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
