Re: Firefox gather candidates for every media track even with max-bundle as bundlePolicy

2017-09-22 Thread prerak jain 
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 <jainpre...@gmail.com> 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

2017-09-21 Thread prerak jain 
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: DTLS 1.1 failure when Firefox 51 is initiating a call

2017-02-01 Thread prerak jain 
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