Re: Firefox and Pipewire

[Nils Ohlmeier]

Hi Charles,

Firefox has some degree of Pipewirre support in its source code 
https://searchfox.org/mozilla-central/search?q=pipewire&path= 
<https://searchfox.org/mozilla-central/search?q=pipewire&path=>
Looks like RedHat is actively maintaining that, as recently as this year.

Personally I don’t know enough about Pipewire to know what it is exactly used 
for, but it appears mostly in the context of screen capturing.
Maybe you can point us at the patch your maintaining on your end to give us an 
idea what it is for.

And yes you should be able to do a very basic screen share test on the gum_test 
page you linked to.

Best
  Nils Ohlmeier

> On 12Mar, 2021, at 08:54, Charles Robertson via dev-media 
>  wrote:
> 
> Hi,
> 
> I'm trying to find information on how Firefox uses Pipewire. We currently 
> package Firefox ESR with a Pipewire patch and I'd like to find out how this 
> patch is being exercised. It seems to have to do with screen sharing. I found 
> this web page that seems to test this but I'm not sure if it is. 
> https://mozilla.github.io/webrtc-landing/gum_test.html
> 
> Can anyone shed some light on this?
> 
> Thank you.
> 
> Charles Robertson
> SUSE - Software Engineer
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox encoding bitrate control

[Nils Ohlmeier]

> On 15Sep, 2020, at 04:44, Edsel Ayala  wrote:
> 
> On Thursday, 28 January 2016 at 04:59:32 UTC+8, ma...@stonethree.com wrote:
>> On Tuesday, December 29, 2015 at 1:28:54 PM UTC+2, Eric Rescorla wrote: 
>>> I'm not sure what you're looking for here. 
>>> 
>>> Nobody's arguing that we shouldn't implement these features, they're just 
>>> not at the top 
>>> of the priority list. If you'd like to submit a patch, it would certainly 
>>> be welcome and one 
>>> of us will be happy to review it. Other than that, I don't know what else 
>>> to tell you. 
>>> 
>>> -Ekr 
>>> 
>>> 
>>> 
>>> On Tue, Dec 29, 2015 at 6:19 AM, Alexander Abagian  
>>> wrote: 
>>> 
>>>> 1.4 mbps is also sad. Too much load for the server. For Chrome I decreased 
>>>> it from 2 to 0.5 - picture quality at 0.5 is good enough. 
>>>> ___ 
>>>> dev-media mailing list 
>>>> dev-...@lists.mozilla.org 
>>>> https://lists.mozilla.org/listinfo/dev-media 
>>>> 
>> Does the same apply for setting the encoding bitrate for opus? 
>> 
>> I.e in chrome the following lines in the sdp can be used to control the 
>> encoding bitrate of the opus codec: 
>> 
>> a=rtpmap: 109 opus/48000/2 
>> a=fmtp:109 maxaveragebitrate=128000; stereo=1; sprop-stereo=1; cbr=1 
>> 
>> Does firefox parse these parameters yet? 
>> 
>> Kind regards, 
>> 
>> Matthew Marsh
> 
> I have the same inquiry, I want to know if there's a way to change the 
> encoding bit rate of opus

We actually landed support for all opus fmtp parameters some time ago. But 
unfortunatelythe feature is blocked by us switching to our new SDP 
parser. Right now it is not 100% when we are going to be able to fully switch 
over to the new parser.

Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: getUserMedia object support

[Nils Ohlmeier]

> On 22May, 2020, at 06:23, alidevelope...@gmail.com wrote:
> 
> On Thursday, December 7, 2017 at 7:28:04 PM UTC+5, fatima-z boujrar wrote:
>> hello
>> 
>> which version of chrome and firefox the object getUserMedia is supported? 
>> because i usually get that error : 
>> 
>> MediaStreamError { name: "NotFoundError", message: "The object can not be 
>> found here.", constraint: "", stack: "" }
>> 
>> in the last versions of chrome and firefox.
>> 
>> any help to fix it please?
> 
> When I try this link which MozCommunity mention , I get following error 
> NotFoundError: The object can not be found here. This same error I had in my 
> website when I had integrated with wrtc  

One possibility why you get this error is that recent versions of Firefox allow 
getUserMedia() only to be called from pages loaded via HTTPS.
Do you use HTTP or HTTPS for your site?

Best
  Nils Ohlmeier


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

Re: Webrtc

[Nils Ohlmeier]

Hello,

> On 14Sep, 2019, at 02:27, sabi.oxo7...@gmail.com wrote:
> 
> I have question... I am using Mozilla Firefox 56 beta 2 version... i try to 
> disable my webrtc but I fail... I added some extensions and use manual method 
> [1st type about:config and enter 2nd click on AT ANY RISK ... 3rd search 
> ( media.peerconnection.enable . 4th click double or right click and select 
> troggy and result is false ... after doing this I restart me browser and when 
> I check my ip then my webrtc still enable . please help me ... I am 
> student and much worried

A couple of points:
First of all if you are worried you should update your Firefox version ASAP. 
The version you use is quite outdated. Lots of security problems have been 
fixed meanwhile. And if you reports issues with such an old version we can’t 
fix them in such old versions.

Secondly I’m wondering what you are worried about.

Lastly: I just switched media.peerconnection.enable to false in Firefox 70 Beta 
and it works for me. Which makes me wonder what do you do to verify if the 
disabling has worked?

Best regards
  Nils Ohlmeier


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

Re: Firefox - Does ICE candidates support domain name?

[Nils Ohlmeier]

Hi Sachin,

> On 30Jul, 2019, at 14:45, Sachin Hambar  wrote:
> 
> Hi All,
> 
> I would like to know whether Firefox supports domain name in ICE candidates. 
> Chrome support it [Reference - 
> https://bugs.chromium.org/p/webrtc/issues/detail?id=4165] 
> 
> RFC support the FQDN i.e. https://tools.ietf.org/html/rfc5245
> 
>  "An IP address SHOULD be used, but an FQDN MAY be
>  used in place of an IP address.  In that case, when receiving an
>  offer or answer containing an FQDN in an a=candidate attribute,
>  the FQDN is looked up in the DNS first using an  record
>  (assuming the agent supports IPv6), and if no result is found or
>  the agent only supports IPv4, using an A.  If the DNS query
>  returns more than one IP address, one is chosen, and then used for
>  the remainder of ICE processing."
> 
> If Firefox does not support it, is there any plan to support in near future.

No it doesn’t support it yet, but we are currently working on adding support 
for mDNS.
mDNS support should probably come in Firefox 70 or 71.

Best regards
  Nils Ohlmeier

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

Re: Firefox fails to gather UDP ICE candidates during ICE restart(network switch)

[Nils Ohlmeier]

Hello,

> On 14Jun, 2019, at 02:03, sha  wrote:
> 
> Hi all,
> 
> I am trying out ICE restart scenario on Firefox and here is the description
> 
> - User A calls User B(both users are on same machine)
> - Machine switches to new wlan(say wlan0 to wlan1)
> - ICE connection state transitions to 'disconnected' for both users
> - User A triggers renegotiation with ICE restart. Only TCP ICE candidates are 
> gathered and call fails eventually
> 
> If the ICE restart is triggered without network interface switch, then 
> Firefox gathers UDP ICE candidates as well and the call works fine.
> 
> The issue can be easily reproduced with WebRTC sample - 
> https://webrtc.github.io/samples/src/content/peerconnection/restart-ice/
> 
> Tested on 
> - Firefox 67.0.1 (64-bit) on Open Suse Leap 42.3 - Fails
> - Firefox 67.0.2 (64-bit) on Windows 10 - Fails
> - Chrome 74.0.3729.169 (64-bit) - Works
> 
> Can anyone confirm if this is issue from Firefox or if there is something 
> wrong with my scenario!

Yes this is a known problem. Firefox currently doesn’t take new interfaces into 
account. Neither automatically nor through ICE restarts.
We have an open bug for it somewhere in bugzilla. I’m not sure when we are 
going to fix it.

Best
  Nils Ohlmeier

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

Re: Could somebody help in analyzing ICE connection logs

[Nils Ohlmeier]

Hello,

based on the logs you should check if you have set 
media.peerconnection.ice.proxy_only to true as well.
If that options is set it means Firefox will only connect through HTTP proxies.
You may either have set this option manually, or some privacy related web 
extensions also set that option.

Best
  Nils

> On Apr 30, 2019, at 08:50, sha  wrote:
> 
> Firefox fails to gather relay candidates only on my machine. 
> 
> Here is my setup
> - Open Suse leap 42.3
> - Firefox - 66.0.3 (64-bit)
> - TURN server - coturn configured to listen on port 192.168.144.87:443 (TCP 
> and TCP/TLS)
> - Forced use of relay candidates - media.peerconnection.ice.relay_only = true
> - No firewall rules
> - ICE config 
>   - turn:webrtc1-144-87.de:443?transport=tcp
>   - turns:webrtc1-144-87.de:443?transport=tcp
> - TURN server URL http://webrtc1-144-87.de/ is reachable from Firefox and 
> maps to IP - 192.168.144.87
> - I make a webrtc audio call
> 
> The same TURN server works fine with Chrome and Firefox on other machines. 
> Also on Wireshark, I see no packets being exchanged between my machine and 
> TURN server either!
> 
> I want help in reading ICE logs to understand why Firefox fails to gather 
> candidates only on this specific machine.
> 
> Thanks for any help!
> --
> ICE logs(about:webrtc)
> 
> ICE(PC:1556636332416317 (id=19327352844 
> url=https://test.de:3443/test_phone.html?c=config&config=test)): relay only 
> option results in no host candidate for IP4:192.168.251.172:0/UDP
> 
> ICE(PC:1556636332416317 (id=19327352844 
> url=https://test.de:3443/test_phone.html?c=config&config=test)): relay/proxy 
> only option results in ICE TCP being disabled
> 
> ICE(PC:1556636332416317 (id=19327352844 
> url=https://test.de:3443/test_phone.html?c=config&config=test)): relay only 
> option results in no host candidate for IP4:192.168.251.172:0/UDP
> 
> ICE(PC:1556636332416317 (id=19327352844 
> url=https://test.de:3443/test_phone.html?c=config&config=test)): relay/proxy 
> only option results in ICE TCP being disabled
> 
> Write buffer not empty for IP4:192.168.144.87:443/TCP 44 - already armed 
> (@0x7f12828051f4), not connected
> 
> NrSocketProxy::OnClose 0x7f1282804c00 reason=2147500037 name=NS_ERROR_FAILURE
> 
> NrSocketProxy::OnClose 0x7f1282805800 reason=2147500037 name=NS_ERROR_FAILURE
> 
> NrSocketProxy::OnClose 0x7f1282806c00 reason=2147500037 name=NS_ERROR_FAILURE
> 
> NrSocketProxy::OnClose 0x7f1282807800 reason=2147500037 name=NS_ERROR_FAILURE
> 
> Write buffer not empty for IP4:192.168.144.87:443/TCP 44 - already armed 
> (@0x7f1282805df4), not connected
> 
> Write buffer not empty for IP4:192.168.144.87:443/TCP 44 - already armed 
> (@0x7f12828071f4), not connected
> 
> Write buffer not empty for IP4:192.168.144.87:443/TCP 44 - already armed 
> (@0x7f1282807df4), not connected
> 
> STUN-CLIENT(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)::TURN): 
> Timed out
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): mode 20, 
> nr_turn_client_error_cb
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)) failed
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): cancelling
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb called with state 4
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb failed
> 
> STUN-CLIENT(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)::TURN): 
> Timed out
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): mode 20, 
> nr_turn_client_error_cb
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)) failed
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): cancelling
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb called with state 4
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb failed
> 
> STUN-CLIENT(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)::TURN): 
> Timed out
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): mode 20, 
> nr_turn_client_error_cb
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)) failed
> 
> TURN(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): cancelling
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb called with state 4
> 
> ICE-CANDIDATE(relay(IP4:192.168.251.172:0/TCP|webrtc1-144-87.de:443)): 
> nr_turn_allocated_cb failed
> 
> STUN-CLIENT(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)::TURN): 
> Timed out
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): mode 20, 
> nr_turn_client_error_cb
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)) failed
> 
> TURN(relay(IP4:192.168.251.172:0/TLS|webrtc1-144-87.de:443)): cancelling
> 
> ICE-CANDIDATE(relay(IP4:19

Re: Firefox fails to accept the remote description if media order is interchanged in SDP

[Nils Ohlmeier]

Hello,

This is the important sentence from the JSEP draft on this topic:

 An m= section is generated for each RtpTransceiver
   that has been added to the PeerConnection, excluding any stopped
   RtpTransceivers; this is done in the order the RtpTransceivers were
   added to the PeerConnection.

Which means these are bugs in Janus and Chrome.
Where is Chrome is “just” showing old behavior in which audio m-section used to 
come always first, before video m-sections.
But Janus is definitely not allowed to swap around m-section, no matter if they 
have mid’s set or not.

Best
  Nils Ohlmeier


> On 21Mar, 2019, at 15:58, Byron Campen  wrote:
> 
> Yes, the order in which transceivers are created (ie; the order that you 
> add tracks) dictates the order of the media sections, and answers must have 
> exactly the same number of media sections in the same order as the offer.
> 
> 
> Best regards,
> 
> Byron Campen
> 
> 
> On 3/20/19 4:33 AM, sha wrote:
>> Hi,
>> 
>> I created a media stream with a video track and then later added a new audio 
>> track to it.
>> 
>> Firefox 66 generates an offer as below
>> 
>> v=0
>> o=mozilla...THIS_IS_SDPARTA-66.0 6649649757650455613 0 IN IP4 0.0.0.0
>> s=-
>> t=0 0
>> a=sendrecv
>> a=fingerprint:sha-256 
>> E6:9C:12:F9:51:3E:FB:66:08:A6:E5:A7:44:3E:C4:2E:4D:5A:65:6F:9F:11:37:5C:B3:6D:70:73:78:78:93:1D
>> a=group:BUNDLE 0 1
>> a=ice-options:trickle
>> a=msid-semantic:WMS *
>> m=video 42914 UDP/TLS/RTP/SAVPF 120 121 126 97
>> c=IN IP4 192.168.144.87
>> a=candidate:0 1 UDP 2122252543 10.0.2.15 53714 typ host
>> a=sendrecv
>> a=end-of-candidates
>> a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
>> a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
>> a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
>> a=fmtp:126 
>> profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
>> a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
>> a=fmtp:120 max-fs=12288;max-fr=60
>> a=fmtp:121 max-fs=12288;max-fr=60
>> a=ice-pwd:885e51aa56ae2c53b752f3ff4b8aa665
>> a=ice-ufrag:b18867cf
>> a=mid:0
>> a=msid:{cb5b1692-3fc4-4398-bd15-389bbb562be4} 
>> {2a72737f-edc9-4db8-b425-7654677d2bb8}
>> a=rtcp:40059 IN IP4 192.168.144.87
>> a=rtcp-fb:120 nack
>> a=rtcp-fb:120 nack pli
>> a=rtcp-fb:120 ccm fir
>> a=rtcp-fb:120 goog-remb
>> a=rtcp-fb:121 nack
>> a=rtcp-fb:121 nack pli
>> a=rtcp-fb:121 ccm fir
>> a=rtcp-fb:121 goog-remb
>> a=rtcp-fb:126 nack
>> a=rtcp-fb:126 nack pli
>> a=rtcp-fb:126 ccm fir
>> a=rtcp-fb:126 goog-remb
>> a=rtcp-fb:97 nack
>> a=rtcp-fb:97 nack pli
>> a=rtcp-fb:97 ccm fir
>> a=rtcp-fb:97 goog-remb
>> a=rtcp-mux
>> a=rtpmap:120 VP8/9
>> a=rtpmap:121 VP9/9
>> a=rtpmap:126 H264/9
>> a=rtpmap:97 H264/9
>> a=setup:actpass
>> a=ssrc:2641968431 cname:{8ec0a58b-8dc5-4bc9-94d8-6296f47ec46d}
>> m=audio 41219 UDP/TLS/RTP/SAVPF 109 9 0 8 101
>> c=IN IP4 192.168.144.87
>> a=candidate:0 1 UDP 2122252543 10.0.2.15 53716 typ host
>> a=sendrecv
>> a=end-of-candidates
>> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
>> a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
>> a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
>> a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
>> a=fmtp:101 0-15
>> a=ice-pwd:885e51aa56ae2c53b752f3ff4b8aa665
>> a=ice-ufrag:b18867cf
>> a=mid:1
>> a=msid:{cb5b1692-3fc4-4398-bd15-389bbb562be4} 
>> {f9022aba-9e72-43fb-b079-8f835482c1cf}
>> a=rtcp:44757 IN IP4 192.168.144.87
>> a=rtcp-mux
>> a=rtpmap:109 opus/48000/2
>> a=rtpmap:9 G722/8000/1
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:101 telephone-event/8000
>> a=setup:actpass
>> a=ssrc:418481083 cname:{8ec0a58b-8dc5-4bc9-94d8-6296f47ec46d}
>> 
>> 
>> This is the answer generate by Janus
>> 
>> v=0
>> o=- 1553073400 1553073401 IN IP4 192.168.251.62
>> s=ect
>> t=0 0
>> a=group:BUNDLE 1 0
>> a=msid-semantic: WMS janus
>> m=audio 9 UDP/TLS/RTP/SAVPF 8
>> c=IN IP4 192.168.251.62
>> a=rtpmap:8 PCMA/8000
>> a=sendrecv
>> a=mid:1
>> a=rtcp-mux
>> a=ice-ufrag:FRNK
>> a=ice-pwd:HHKPDngakgsincsuubCf4g
>> a=ice-options:trickle
>> a=fingerprint:sha-256 
>> D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
>> a=setup:active
>> a=ssrc:91094205 cname:janus
>> a=ssrc:91094205 msid:janus janusa0
>> a=ssrc:91094205

Re: how to disable SRTP

[Nils Ohlmeier]

Hi Alexander,

> On 1Mar, 2019, at 09:00, Alexander Abagian  wrote:
> I know that Firefox does not have such a useful thing as 
> -disable-webrtc-encryption. Could somebody recommend a way to modify Firefox 
> sources to build a custom build with SRTP off ? Best of all if DTLS would 
> stay on but SRTP does not encrypt RTP. I need to investigate H.264 in 
> Wireshark.
> 
> The way to make a text RTP log and converting it to pcap seems to be too 
> annoying.

I see this as user security vs. developer convenience trade off. How often do 
you as a developer need to have network packets in the clear?
I would assume you are debugging one problem for a couple of days or weeks. And 
then you don’t need that feature for a long time any more.
Where is having the code ready in the build product to disable encryption is an 
additional risk for the user to be abused.

And why would you want DTLS with SRTP disabled?
It’s only needed to negotiate the keys for SRTP and for continuously protecting 
the data channel.

Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Intent to remove DHE ciphers in Fx 64 (Was: Intent to remove DHE ciphers from WebRTC DTLS handshake)

[Nils Ohlmeier]

As the Telemetry data [1] shows no significant usage of the DHE ciphers in Beta 
63 and Nightly 64 we are planing to remove the DHE ciphers in Firefox 65.

Please voice your concerns now, if you have any.

Best
  Nils Ohlmeier

[1] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-10-01&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F63&measure=WEBRTC_DTLS_CIPHER&min_channel_version=nightly%252F60&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-09-04&table=1&trim=0&use_submission_date=0

> On Aug 29, 2018, at 3:56 PM, Nils Ohlmeier  wrote:
> 
> Summary:
> 
> We are looking at removing the DHE cipher suites from the DTLS handshake in 
> Firefox soon.
> 
> Ciphers:
> - TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
> - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> are the  two suites which we want to remove, because they are considered too 
> weak.
> 
> A Telemetry probe landed in Firefox 63 Nightly to monitor the usage of the 
> different cipher suites:
> https://telemetry.mozilla.org/new-pipeline/dist.html#measure=WEBRTC_DTLS_CIPHER
>  
> <https://telemetry.mozilla.org/new-pipeline/dist.html#measure=WEBRTC_DTLS_CIPHER>
> 
> Bug tracking the deactivation:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1227519 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1227519>
> 
> Targeted release: Firefox 66
> 
> Best
>   Nils Ohlmeier

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

Re: QoS & DSCP

[Nils Ohlmeier]

Hello Alexander,

> On Jul 12, 2018, at 11:24, Alexander Abagian  wrote:
> Is there any support for QoS in Firefox WebRTC now ?

No.
You probably want to follow this bug report 
https://bugzilla.mozilla.org/show_bug.cgi?id=1249575 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1249575>

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

Firefox 61 release notes available

[Nils Ohlmeier]

Hello,

The Firefox 61 (currently in Beta cycle - becoming release on 2018-06-26) 
release notes are available now here 
https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/61 
<https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/61>

Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: No audio on firefox for inbound calls

[Nils Ohlmeier]

Well the same questions I asked already for the original request:

Do you know if Asterisk suddenly has a full ICE implementation?

Feel free to open a bug report for the potential problem in Firefox of 
switching ICE roles from controlled to controller. But the role switching 
delays call establishing. That’s why I think you should do one of these:
- The real fix here is probably to teach Asterisk that it needs to be the ICE 
controller if it sends the offer.
- Switch around the offer/answer roles, so that Firefox create the offer and 
Asterisk the answer might solve this problem as well.

Best
  Nils Ohlmeier

> On Apr 24, 2018, at 09:01, massimo.cime...@ennova-research.com wrote:
> 
> On Friday, April 20, 2018 at 11:37:05 PM UTC+2, sergio.mig...@gmail.com wrote:
>> Hello, In my webrtc project I not getting audio for all inbound calls, some 
>> of them don't get audio. Because the event iceConnectionState= connected 
>> never arrives.
>> 
>> I'm using the asterisk 13.20 and the kamailio 4.4.6 version.
>> 
>> For signaling I have a server with a REST API to exchange the sip messages.
>> In the javascript I using this webrtc-adapter 
>> https://www.npmjs.com/package/webrtc-adapter
>> 
>> Can anyone help me with this problema, Than you.
>> 
>> The flow in my javascript when I start the application and receive a call is 
>> the following:
>>  1 - Execute GetUserMedia and save the stream received.
>>  2 - Add the eventHandlers to the peerconnection
>>  2 - Receive an offer (call), get the tracks from the localstream, and 
>> execute the addTrak of the peeConnection, to add the traks and the local 
>> stream to the peerConnection
>>  3 - The user click a button to answer the call
>>  4 - set remoteDescription of the received offer
>>  5 - Create an answer without RTCOfferOptions
>>  6 - setLocaldescription
>>  7 - wait (using promises) until receive at least 2 candidates of the 
>> type srflx or until the Ice gathering is complete
>>  8 - When the Promise is resolved, an answer to the offer is sent to 
>> asterisk. The offer contains the sdp with the candidates 
>> (peerConnection.LocalDescription.sdp).
>>  9 - After the answer been sent, I execute the play to the audio 
>> htmlElement. This element will have the property srcObject with the remote 
>> stream received in the event ontrack.
>> 
>> My configfuration of the peerConnection is the following:
>> 
>> var pcConfig: any = {
>>'iceServers':
>>[{urls: [
>>"stun:stun4.l.google.com:19302"
>>]}],
>>'rtcpMuxPolicy': 'negotiate'
>>}
>> 
>> Using my app I get the following log from the firefox (about:webrtc):
>> 
>> Session Statistics
>> [ 10737418249 ] http://wksms4/uAgentWeb_IS/Main.aspx (fechada) 18:38:05 
>> GMT+0100 (GMT Daylight Time)
>> ID da ligação do par: 1524245864454000 (id=10737418249 
>> url=http://wksms4/uAgentWeb_IS/Main.aspx)
>> 
>> ICE Statistics
>> local candidate  remoto candidate
>> ICE state   PriorityNomenated
>>SelectedBytes Sent  Bytes Received
>> 172.30.161.79:55472/udp(host)10.2.185.67:14782/udp(host) 
>> succeeded   9115005270299247000 false   false   0
>>0
>> 172.30.161.79:55473/udp(host)10.2.185.67:14783/udp(host) 
>> succeeded   9115005266004279000 false   false   0
>>0
>> 
>> Reinícios ICE: 0
>> Reversões ICE: 0
>> 
>> 
>> All raw candidates
>> Local Raw Candidadte Remote raw 
>> candidate
>> host(IP4:172.30.161.79:55472/UDP)candidate:Ha02b943 1 
>> UDP 2130706431 10.2.185.67 14782 typ host
>> host(IP4:172.30.161.79:55473/UDP)candidate:Ha02b943 2 
>> UDP 2130706430 10.2.185.67 14783 typ host
>> host(IP4:172.30.161.79:56089/TCP) active
>> host(IP4:172.30.161.79:60255/TCP) active
>> srflx(IP4:172.30.161.79:55472/UDP|stun4.l.google.com:19302)
>> srflx(IP4:172.30.161.79:55473/UDP|stun4.l.google.com:19302)
>> 
>> SDP
>> Local SDP (Answer)
>> 
>> v=0
>> o=mozilla...THIS_IS_SDPARTA-59.0.2 4366187553463619912 0 IN IP4 0.0.0.0
>> s=-
>> t=0 0
>> a=sendrecv
>> a=fingerprint:sha-256 
>> 01:BD:59:4E:CB:CE:80:20:1D:81:4C:42:6A:32

Re: Where to get Firefox WebRTC feature updates?

[Nils Ohlmeier]

Hi Juan,

> On Apr 11, 2018, at 07:03, Juan Navarro  wrote:
> I'm aware of Firefox Platform Status (https://platform-status.mozilla.org/) 
> but I'd like to know if there are other sources of information for updates on 
> the Firefox WebRTC features; maybe some place where announcements are made 
> just like the PSAs done in the discuss-webrtc group 
> (https://groups.google.com/forum/#!forum/discuss-webrtc)
> 
> For example, a month ago I wanted to track implementation of the 
> RTCRtpSender.replaceTrack() method. For Chrome this was easy: their Platform 
> Status website had (still has) an entry called "RTCRtpSender.replaceTrack" 
> where it stated that the planned release version would be 65; and also the 
> discuss-webrtc group has (coincidentally today in the first position) an 
> entry named "PSA: replaceTrack() shipping in M65", where they give more 
> detail.
> 
> However, in Mozilla's Platform Status website there are no results for either 
> "replaceTrack", "RTCRtpSender", or "RTCRtpSender.replaceTrack". There are not 
> many useful results either in this google group. However I'm pretty sure the 
> replaceTrack feature has been developed between Firefox versions 58 and 59: 
> in Firefox 58, sender.replaceTrack(null) wasn't supported, but in Firefox 59 
> this call started working. So, support for a 'null' argument has been added.
> 
> I just would like to know if there would have been some resource where I 
> could have known ahead of time (say a month ago) that this feature was going 
> to be added to Firefox 59. Same for other similar features.

Let me start with pointing out that we try to publish Firefox WebRTC Release 
Notes shortly after a new version of Firefox gets started. For example for 
Firefox you can find them here 
https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/59 
<https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/59>
And for the current Firefox Beta 60 they are here 
https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/60 
<https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/60>

In the future I’ll try to send out emails to this list when new release notes 
are available.

Normally I would also point you at MDN for documentation of features in 
Firefox. But it seems that the documentation for replaceTrack() is actually 
missing in there - I notified our MDN folks about it.

In terms of your specific issue my guess is that it is a side effect of 
Transceivers becoming available in Firefox 59, and not specific work on 
replaceTrack().

And lastly we encourage everyone working on or with WebRTC to always test with 
Firefox Nightly or at lest Beta to ensure their products keep working with 
browser implementations which try to keep up with the changing WebRTC spec as 
good as they can.

Best regards
  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

Re: Fake Media Streams for getUserMedia()

[Nils Ohlmeier]

Yes it should be supported. Which platform and Fx version are you experiencing?

I think there is a problem pulse audio on Linux in 58 which might affect you 
gUM.
And I think we have another open bug which affects ‘fake’ if there are no 
sounds devices available at all.

Best
  Nils

> On Mar 8, 2018, at 11:41, moriahma...@gmail.com wrote:
> 
> Is using the parameter fake: true in getUserMedia() still the way to use a 
> fake media stream in Firefox? I cannot find documentation on it anywhere and 
> am battling a bug where getUserMedia() hangs on SauceLabs when the parameter 
> fake: true is specified.
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC ICE failing on Firefox 57 (64-bit Linux) when trying to connect via OpenVPN to LAN

[Nils Ohlmeier]

Hi Rob,

Can you please describe in more detail you think is an/the issue here?

Because at the end of your mail I see a list of host candidate plus two server 
reflexive candidates. That matches exactly what I get on that page as well, and 
is exactly what I would expect to happen on a page which provides a STUN server.

Best regards
  Nils Ohlmeier

> On Feb 24, 2018, at 22:16, r...@iblargz.com wrote:
> 
> Having this issue as well, I'm not sure it's related to Janus or docker 
> (tested w/ and without).
> 
> I'm able to reproduce the issue on:
> 
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> 
> with google's stun server, my own stun servers, and turn servers.
> 
> 
> Don't worry Lorenzo, it's short won't need to scroll 3-4 times :)
> Here's the connection log:
> 
> ---
> Exit UDP socket connected
> 
> UDP socket error:Internal error at 
> /builds/worker/workspace/build/src/dom/network/UDPSocketParent.cpp:283 
> this=0x1150f9000
> 
> /builds/worker/workspace/build/src/media/mtransport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:173
>  function nr_socket_multi_tcp_create_stun_server_socket skipping UDP STUN 
> server(addr:)
> 
> /builds/worker/workspace/build/src/media/mtransport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:617
>  function nr_socket_multi_tcp_listen failed with error 3
> 
> ICE(PC:1519538703129416 (id=2147483696 
> url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)):
>  failed to create passive TCP host candidate: 3
> 
> /builds/worker/workspace/build/src/media/mtransport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:173
>  function nr_socket_multi_tcp_create_stun_server_socket skipping UDP STUN 
> server(addr:)
> 
> /builds/worker/workspace/build/src/media/mtransport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:617
>  function nr_socket_multi_tcp_listen failed with error 3
> 
> ICE(PC:1519538703129416 (id=2147483696 
> url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)):
>  failed to create passive TCP host candidate: 3
> 
> STUN-CLIENT(srflx(IP4:10.88.111.3:64862/UDP|stun.l.google.com:19302)): 
> Received response; processing
> 
> STUN-CLIENT(srflx(IP4:10.88.111.3:63389/UDP|stun.l.google.com:19302)): 
> Received response; processing
> 
> ICE(PC:1519538703129416 (id=2147483696 
> url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)):
>  peer (PC:1519538703129416 (id=2147483696 
> url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/):default)
>  has no stream matching stream 0-1519538703129416 (id=2147483696 
> url=https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) 
> aLevel=0
> 
> +++ END 
> ---
> 
> And the candidates:
> ---
> Time  Component   TypeFoundation  ProtocolAddress Port
> Priority
> 0.005 1   host0   UDP 10.88.111.3 64862   126 | 32512 | 
> 255
> 0.005 1   host2   TCP 10.88.111.3 9   125 | 32704 | 
> 255
> 0.007 2   host0   UDP 10.88.111.3 63389   126 | 32512 | 
> 254
> 0.008 2   host2   TCP 10.88.111.3 9   125 | 32704 | 
> 254
> 0.035 1   srflx   1   UDP 64.137.149.59   64862   100 | 32543 | 
> 255
> 0.055 2   srflx   1   UDP 64.137.149.59   63389   100 | 32543 | 
> 254
> 0.056 Done
> ---
> 
> Tested on: 58.0.2 (64-bit) - macOS 10.13.1
> 
> I even see it happening on mixer.com but a single peerreflexive managed to 
> establish.
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Can't view WebRTC stream from Janus WebRTC Gateway in Firefox

[Nils Ohlmeier]

Hi Rhythm,

I’m not an expert in reading Janus logs, but I noticed two differences in the 
logs you provided.

- In the Chrome log I see two ICE candidates from Janus, one for 192.168.x.x 
and one for 43.224.x.x.x. But in the Firefox log I only see the non-routable 
ICE candidate for 192.168.x.x. This would explain why ICE connection can’t get 
established. I would recommend to find out why in the Firefox case there is no 
public IP ICE candidate.

- In the Chrome log I see a local SDP (sips -> local) and remote SDP (spds -> 
remote). But in the Firefox log the remote SDP is missing. Without the remote 
SDP the ICE connection and DTLS won’t get established. This is the first 
problem I would try to debug/solve.

Best regards
  Nils Ohlmeier

> On Feb 24, 2018, at 11:48, Rhythm Chopra  wrote:
> 
> I need to RTP media stream coming from Gstreamer over Web Browser, so I am 
> using Janus WebRTC Gateway for the same. Media stream appears fine in Chrome, 
> but when I try to view the same stream in Firefox, it can't view any stream, 
> moreover the console throws me an error `ICE failed, add a TURN server and 
> see about:webrtc for more details`. On debugging Janus, thorough its Admin 
> API, I figured out that Firefox can't get Remote SDP, whereas Chrome get it. 
> SDP Session state in firefox stays at `gathering` forever, but as soon as it 
> changes to `ready` in Chrome, the stream appears.
> 
> Following are the Session logs for Chrome and FireFox:
> Session Logs for Chrome: https://pastebin.com/WEkMj5DW
> Session Logs for Firefox: https://pastebin.com/wmM6YKJK
> 
> On further debugging, I found out that answer created for SDP negotiation by 
> RTCPeerConnection.createAnswer() returns the answer with attribute 
> `rtpmap:120 VP8/9` whereas, my stream is `H264/9` encoded. Is there a 
> way I can create a valid answer for SDP negotiation for H264 encoded stream.
> 
> Please suggest.
> 
> Regards,
> Rhythm
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: What does 'Skipping TURN server because of link local mis-match' means?

[Nils Ohlmeier]

Kensaku,

Can you please set the env variables from this section 
https://wiki.mozilla.org/Media/WebRTC/Logging#ICE.2FSTUN.2FTURN 
<https://wiki.mozilla.org/Media/WebRTC/Logging#ICE.2FSTUN.2FTURN>
But set the log level to 9 (instead of 3).
If you could send the resulting log file to Byron and/or me I think we can 
figure out what is going wrong in your setup.

Best
  Nils Ohlmeier

> On Jan 9, 2018, at 01:13, Andreas Pehrson  wrote:
> 
> You have one remote candidate that uses IPv6. The error you mention in
> about:webrtc is likely from that candidate and not related to why the relay
> candidate disappears.
> 
> To answer what happens to the relay candidate, I'll have to defer to a
> colleague who knows the signaling stack better. Byron should be able to
> help.
> 
> On Mon, Jan 8, 2018 at 8:08 PM, KOMATSU Kensaku 
> wrote:
> 
>> Hi Andreas,
>> 
>> Thanks for your reply.
>> 
>> I checked address range of my environment, but my env did not have
>> 169.254/16 in ICE candidates.
>> 
>> I tested this issue again. Then, I found that behavior got different after
>> FF58.
>> 
>> With 57.0.4 (64 bit), it worked well with TURN since remote-candidates of
>> Janus Admin log included ``relay`` candidates as follows,
>> 
>> ```
>> "local-candidates": [
>>"1 1 udp 2013266431 10.0.2.15 52855 typ host",
>>"2 1 udp 167772671 52.41.145.197 59022 typ relay
>> raddr 10.0.2.15 rport 0",
>>"3 1 udp 1677722111 165.254.239.194 24786 typ
>> srflx raddr 10.0.2.15 rport 52855"
>>],
>>"remote-candidates": [
>>"0 1 UDP 2122187007 10.49.52.222 64179 typ host",
>>"4 1 UDP 2122252543 
>> 2001:418:149f:1052:9d6d:7332:3369:7126
>> 64180 typ host",
>>"9 1 UDP 8265727 52.41.145.197 50133 typ relay
>> raddr 52.41.145.197 rport 50133",
>>"1 1 UDP 1685987327 165.254.239.194 17963 typ
>> srflx raddr 10.49.52.222 rport 64179"
>>],
>> ```
>> 
>> But 58.0b14 (64-bit) and 59.0a1 (2018-01-08) (64 bit), it failed with
>> skipping ``relay`` candidate from remote-candidates.
>> 
>> ```
>> "local-candidates": [
>>"1 1 udp 2013266431 10.0.2.15 54551 typ host",
>>"2 1 udp 167772671 52.41.145.197 54316 typ relay
>> raddr 10.0.2.15 rport 0",
>>"3 1 udp 1677722111 165.254.239.194 21385 typ
>> srflx raddr 10.0.2.15 rport 54551"
>>],
>>"remote-candidates": [
>>"0 1 UDP 2122252543 10.49.52.222 56774 typ host",
>>"4 1 UDP 2122187007 
>> 2001:418:149f:1052:9d6d:7332:3369:7126
>> 54378 typ host",
>>"1 1 UDP 1686052863 165.254.239.194 15475 typ
>> srflx raddr 10.49.52.222 rport 56774"
>>],
>> ```
>> 
>> Also, I saw "Skipping TURN server because of link local mis-match" in
>> about:webrtc.
>> 
>> 
>> 
>> 2018年1月5日金曜日 5時36分43秒 UTC-8 Andreas Pehrson:
>>> Hi Kensaku,
>>> 
>>> Looking at our code, the error originates at one of the two checks in
>> [1].
>>> 
>>> "link local" seems to refer to an address in the 169.254/16 range.
>> There's
>>> a similar check for ipv6. Does your server sit in this range?
>>> 
>>> We also raise the same error in case of a mismatch between your local
>>> interface's and the turn server's ip address version (4 vs 6).
>>> 
>>> I suppose there is a chance of false positives during enumeration of all
>>> interfaces re the version check. Does the server show up in the table on
>>> about:webrtc?
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> Andreas
>>> 
>>> 
>>> [1]
>>> https://searchfox.org/mozilla-central/source/media/
>> mtransport/third_party/nICEr/src/net/transport_addr.c#488-497
>>> 
>>> On Fri, Jan 5, 2018 at 2:45 AM,  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I am trying to make webrtc connection between Janus in vagrant and FF
>> (=<
>>>> 57) on host machine. But it make an ice failed error (Chrome works
>> fine

Re: WebRTC ICE failing on Firefox 57 (64-bit Linux) when trying to connect via OpenVPN to LAN

[Nils Ohlmeier]

Hi Mikael,

Could you please send me a copy go the connection log at the bottom of the 
about:webrtc  page.
Even better would be pcap trace file taken with tcpdump or wireshark of the 
problem.

Thank you
  Nils Ohlmeier

> On Dec 11, 2017, at 01:44, Mikael Nousiainen  wrote:
> 
> I have a working Janus WebRTC server setup running in my LAN (streaming only 
> live Opus audio). With direct connections -- while connected to the LAN -- it 
> works perfectly every time with Firefox, Chrome, Chromium and the mobile 
> browsers.
> 
> However, when I connect to the LAN from the public Internet via OpenVPN, 
> Firefox states that ICE fails and does not output any audio, but Chrome and 
> Chromium (latest versions) _do work_ always.
> 
> I'm not using a STUN or TURN server, because WebRTC should work fine inside 
> LAN.
> Also, There are no firewalls on traffic restrictions in place inside my LAN 
> or the connecting workstation.
> 
> Here are the about:webrtc SDP details from Firefox:
> 
> SDP
> 
> Local SDP
> 
> v=0
> o=mozilla...THIS_IS_SDPARTA-57.0 1746241924783914147 0 IN IP4 0.0.0.0
> s=-
> t=0 0
> a=sendrecv
> a=fingerprint:sha-256 
> A5:C9:2F:26:99:CF:7A:1E:6B:39:F9:56:4D:A7:6C:44:6A:C6:C7:B8:90:9D:17:E7:E3:BA:4E:CE:AB:DB:18:0E
> a=group:BUNDLE audio
> a=ice-options:trickle
> a=msid-semantic:WMS *
> m=audio 4187 RTP/SAVPF 101
> c=IN IP4 85.76.X.X
> a=candidate:0 1 UDP 2122252543 192.168.43.135 39927 typ host
> a=candidate:2 1 TCP 2105524479 192.168.43.135 9 typ host tcptype active
> a=candidate:1 1 UDP 1686052863 85.76.X.X 4187 typ srflx raddr 192.168.43.135 
> rport 39927
> a=recvonly
> a=end-of-candidates
> a=fmtp:101 maxplaybackrate=48000;stereo=1;useinbandfec=1
> a=ice-pwd:8ce147a6798654432b88ded1a0441e99
> a=ice-ufrag:b273b366
> a=mid:audio
> a=rtcp-mux
> a=rtpmap:101 opus/48000/2
> a=setup:active
> a=ssrc:675509201 cname:{5784c74c-8d73-4877-b111-0ff72b1bb6d0}
> 
> Remote SDP
> v=0
> o=- 1512977090487910 1512977090487910 IN IP4 192.168.0.114
> s=-
> t=0 0
> a=sendrecv
> a=group:BUNDLE audio
> a=msid-semantic:WMS janus
> m=audio 9 RTP/SAVPF 101
> c=IN IP4 192.168.0.114
> a=candidate:1 1 udp 2013266431 192.168.0.114 51415 typ host
> a=sendonly
> a=end-of-candidates
> a=fingerprint:sha-256 
> A8:A2:A0:A6:36:95:6F:17:02:B7:B9:02:61:06:DC:FA:65:14:F4:3C:1E:C5:60:72:97:10:11:F5:0C:A2:00:6A
> a=ice-options:trickle
> a=ice-pwd:hy7+LKuhl8w3q3oLRYja+R
> a=ice-ufrag:d/gM
> a=mid:audio
> a=rtcp-mux
> a=rtpmap:101 opus/48000/2
> a=setup:actpass
> a=ssrc:3533275855 cname:janusaudio
> a=ssrc:3533275855 msid:janus janusa0
> a=ssrc:3533275855 mslabel:janus
> a=ssrc:3533275855 label:janusa0
> 
> RTP Stats
> inbound_rtp_audio_0
> 
> Local: 09:24:57 GMT+0200 (EET) inbound-rtp SSRC: 0
> 
> Here are the Firefox trickle candidates when connecting via VPN:
> 
> candidate:0 1 UDP 2122252543 192.168.43.135 39927 typ host
> candidate:2 1 TCP 2105524479 192.168.43.135 9 typ host tcptype active
> candidate:1 1 UDP 1686052863 85.76.X.X 4187 typ srflx raddr 192.168.43.135 
> rport 39927
> 
> 192.168.43.135 is the address provided by mobile phone WiFi tethering network.
> 85.76.X.X is the public IP address of the phone (which shouldn't really be 
> needed here, as traffic should flow through OpenVPN).
> 
> After the trickle candidates have been sent, Janus sends back response:
> 
> {
> janus: "hangup"
> reason: "ICE failed"
> ...
> }
> 
> And Janus logs state the same:
> 
> [8217140053462936] ICE failed for component 1 in stream 1, but let's give it 
> some time... (trickle received, answer received, alert not set)
> 
> For comparison, here are the offer and answer SDPs and the only trickle 
> candidate from Chromium, where the WebRTC audio stream works:
> 
> SDP offer (Chromium):
> 
> v=0
> o=- 1512977894982229 1512977894982229 IN IP4 192.168.0.114
> s=Mountpoint 101
> t=0 0
> a=group:BUNDLE audio
> a=msid-semantic: WMS janus
> m=audio 9 RTP/SAVPF 101
> c=IN IP4 192.168.0.114
> a=sendonly
> a=mid:audio
> a=rtcp-mux
> a=ice-ufrag:UF1c
> a=ice-pwd:AEcwbtUvOOlWmHrqxMNvs9
> a=ice-options:trickle
> a=fingerprint:sha-256 
> A8:A2:A0:A6:36:95:6F:17:02:B7:B9:02:61:06:DC:FA:65:14:F4:3C:1E:C5:60:72:97:10:11:F5:0C:A2:00:6A
> a=setup:actpass
> a=rtpmap:101 opus/48000/2
> a=ssrc:1652840103 cname:janusaudio
> a=ssrc:1652840103 msid:janus janusa0
> a=ssrc:1652840103 mslabel:janus
> a=ssrc:1652840103 label:janusa0
> a=candidate:1 1 udp 2013266431 192.168.0.114 50486 typ host
> a=end-of-candidates
> 
> SDP answer (Chromium):
> 
> v=0
> o=- 4097746442121410971 2 IN IP4 127.0.0.1
> s=-
> t=0 0

Re: H.264+rtcp=no lost packets report

[Nils Ohlmeier]

Hi Warp,

> On Oct 24, 2017, at 14:31, Wild Ranger  wrote:
> 
> After some traces and debug i find that problem not in rtcp but in cpu load. 
> Firefox 56 stop send self video on hard load ~ after 25 seconds. In FF 57 
> that is beta FF not stop send video but down resolution what is more correct.

Thanks a lot for tacking it down. Yeah that is a known problem we tried to warn 
about publicly as much as possible: 
https://blog.mozilla.org/webrtc/when-your-video-freezes/ 
<https://blog.mozilla.org/webrtc/when-your-video-freezes/>
It seems like that our messaging didn’t reach you.

Best regards
  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

Re: Firefox silently discarding RTP payload

[Nils Ohlmeier]

> On Sep 28, 2017, at 21:36, Michael Froman  wrote:
> 
> Hello,
> 
> The RTP logger only logs the packet header, not the payload.  The first step 
> would be to go to the about:webrtc page, and click the ‘Save Page’ button.  
> The best option would be to open a bug and attach that file to the new bug.  
> Please let us know the bug number.

Michael is right that the RTP logger on purpose over writes the biggest part of 
the payload with zeros. So zero’s in the result of logger do not tell you 
anything about any decoding errors.
But the first few bytes after the RTP header do get logged to allow you to peak 
into the payload. So you should in Wireshark see after the RTP header the Opus 
header. The Opus payload will be mostly zeros.

Best
  Nils

> Thank you!
> Michael.
> 
>> On Sep 28, 2017, at 8:29 AM, gtm.ma...@gmail.com wrote:
>> 
>> I'm trying to create an audio mixing server using Janus, but every packet 
>> the client receives is having all data after the packet header completely 
>> discarded by firefox with no message explaining why. I've tried enabling 
>> logging using the about:webrtc and about:networking pages, but nothing is 
>> ever written to the WebRTC.log file, so I've been using MOZ_LOG instead with 
>> the following modules 
>> "sync,timestamp,rtplogger:5,webrtc_trace:5,MediaManager:5,MediaStream:5,MediaStreamGraph:5,MediaEncoder:5,TrackEncoder:5".
>> 
>> When looking through the log file I noticed the rtplogger in the socket 
>> thread outputs each packet's contents and everything after the header is 
>> always straight zeros. At the same time I captured those packets in 
>> wireshark and the packet data is showing up just fine. I assumed firefox was 
>> encountering an error when decoding the opus stream in the packet, but I set 
>> up the server to write each packet to an ogg file before sending them out to 
>> the clients and I was able to play back that file without any issues, so the 
>> encoded audio doesn't seem to be malformed. The only other possible cause I 
>> can think of is improper settings for the client's opus decoder, but all the 
>> settings for the server's encoder match up with the remote SDP description, 
>> so the client's decoder should be properly configured to decode the audio.
>> 
>> I have been testing using Firefox Developer Edition v57.0b2 (64 bit). Any 
>> assistance would be greatly appreciated and if there's any more information 
>> I can provide please let me know.
>> ___
>> dev-media mailing list
>> dev-media@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-media
> 
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: video channel count limitation

[Nils Ohlmeier]

Hi Alexander,

> On Sep 22, 2017, at 10:28, Alexander Abagian  wrote:
> 
> Is there an internal limit for video channel or m-sections count in the 
> RTCPeerConnection ? I have a case when the seventh (usually) participant 
> video in a WebRTC conference client is not shown. Sometimes it could be 8, 
> and if they were added very quickly by special load client, then it's 10. I 
> don't see any important difference between visible and invisible videos, аnd 
> firefox extended log is also has no errors. If seven participant are added, 
> then usually videos from first six one are visible, and the seventh of not; 
> but if I remove the sixth one, the seventh begins to be visible.

No there should be no limitation in the amount of m-sections. And I’m also not 
aware of any limitation in the amount of video streams or renderers.
Just to be sure: if you are talking about a full mesh call here I would expect 
that 7-8 participants is right around the maximum load one can achieve on 
reasonably fast machine. But since you are using the word server I assume this 
is in a star topology with some form of SFU in the middle. If that is the case 
then this sounds more like a bug in Firefox to me which should investigate. 
Could please fill a bug report on bugzilla.mozilla.org 
<http://bugzilla.mozilla.org/> about this?

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

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

[Nils Ohlmeier]

Well we have a bug for it https://bugzilla.mozilla.org/show_bug.cgi?id=1339203 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1339203> which is in our regular 
back log.
And it is on our agenda for the rest of the year.

> On Sep 21, 2017, at 22:08, Martin Thomson  wrote:
> 
> Support for RTCP mux is now mandatory.  Nils, do you have any plans
> for trimming down the extra gathering?  I appreciate that it might be
> a low priority item.
> 
> On Fri, Sep 22, 2017 at 11:05 AM, 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
>> 
>> 
>> ___
>> dev-media mailing list
>> dev-media@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-media
>> 



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

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

[Nils Ohlmeier]

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



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: renegotiation setLocalDescription crash on video

[Nils Ohlmeier]

Hi Eric,

> On Aug 23, 2017, at 08:34, Eric Green  wrote:
> 
> Hi,
> 
> I am working on implementing renegotiation into SIP.js, specifically looking 
> at hold/unhold via changing SDP attributes to sendonly. This is working when 
> Firefox negotiates audio only, or is the person triggering the renegotiation. 
> The problem starts when Firefox is doing a video call and is the target of 
> being put on hold. The browser will receive an SDP offer with a=sendonly for 
> both video and audio sections of the call. I successfully apply this to the 
> peer connection and the peer connection changes to have-remote-offer state. I 
> can successfully call createAnswer, generate the RTCSessionDescription, but 
> when I call setLocalDescription on my peer connection with the answer from 
> createAnswer, the browser will lock up.
> 
> This is one of my crash reports: 
> https://crash-stats.mozilla.com/report/index/9de4defb-5a39-4950-9f7f-c8e060170823
> 
> I could put together a simple demo to replicate this if needed. It is 
> happening in both the production version of Firefox and the Developer build. 
> Chrome is working successfully with the same javascript.
> 
> Any thoughts on what I can do to make Firefox not crash on this?

From looking at the crash report it would be super helpful if you could send me 
a way to reproduce this, e.g. point me to github page with code, or a link to 
web page for testing.
Or open a bug report about it on https://bugzilla.mozilla.org 
<https://bugzilla.mozilla.org/>
Which ever is easier for you.

Thank you very much in advance
  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

Re: Webrtc Simulcast: FF sending only one stream in simulcast enabled RTP session

[Nils Ohlmeier]

Hi Ashwin,

> On Jul 6, 2017, at 03:24, Ashwin Kumar  wrote:
> 
> Looks like adding maxBitrate to the encoding params helped. Now I see that FF 
> is transmitting all three streams.
> 
> But like Lorenzo, I also have the same question - "what's the syntax for 
> maxBitrate? is it in bps? Asking as the 4 in the example seems quite low. 
> “

As I replied to Lorenzo before already: the reason the number is so low is that 
we are running all of our automated tests on super low resolutions to save 
resources.

Best
  Nils


> 
> On Thursday, July 6, 2017 at 1:13:34 PM UTC+5:30, Lorenzo Miniero wrote:
>> Il giorno giovedì 6 luglio 2017 01:13:01 UTC+2, Nils Ohlmeier ha scritto:
>>>> 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
>>>  
>>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62>
>>>  
>>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62
>>>  
>>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62>>
>>> 
>> 
>> 
>> Hi Nils,
>> 
>> as a side note, what's the syntax for maxBitrate? is it in bps? Asking as 
>> the 4 in the example seems quite low.
>> 
>> Thanks,
>> Lorenzo
>> 
>> 
>>>> 
>>>> 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
> 
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org <mailto:dev-media@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-media 
> <https://lists.mozilla.org/listinfo/dev-media>


signature.asc
Description: Message signed with OpenPGP
___
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

[Nils Ohlmeier]

> On Jul 6, 2017, at 00:43, Lorenzo Miniero  wrote:
> 
> Il giorno giovedì 6 luglio 2017 01:13:01 UTC+2, Nils Ohlmeier ha scritto:
>>> 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
>>  
>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62>
>>  
>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62
>>  
>> <http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62>>
>> 
> 
> 
> Hi Nils,
> 
> as a side note, what's the syntax for maxBitrate? is it in bps? Asking as the 
> 4 in the example seems quite low.

That value is only artificially low in our CI tests, as run everything with 
super low resolutions to be able to execute the tests on slow machines.
So if I’m not mistaken this is in fact bps.

Best
  Nils



signature.asc
Description: Message signed with OpenPGP
___
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

[Nils Ohlmeier]

> 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
 
<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



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: has no stream matching stream

[Nils Ohlmeier]

Hi Alexander,

> On Jun 26, 2017, at 12:08, Alexander Abagian  wrote:
> I've got a about:webrtc log for a quite big webrtc conference with a lot of 
> lines in like these:
> 
> (ice/WARNING) ICE(PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference)): peer 
> (PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference):default) has no stream 
> matching stream 0-1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference) aLevel=2
> (ice/WARNING) ICE(PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference)): peer 
> (PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference):default) has no stream 
> matching stream 0-1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference) aLevel=3
> (ice/WARNING) ICE(PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference)): peer 
> (PC:1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference):default) has no stream 
> matching stream 0-1498488600251000 (id=47 
> url=https://go.muppetshow.com/service/wconference) aLevel=4

Usually that warning is benign, as it comes up when for example the other side 
sends you ICE candidates for the RTCP component, but both sides agreed already 
to use rtcp-mux instead.
Especially when ICE succeeds I think it’s pretty safe to ignore the warning.

> 
> ICE is succeeded, but there's no incoming video for anyone there.
> 
> What do these message mean ? Could it show that m-sections were messed and 
> incoming streams went to wrong m-section ?

I think with ICE succeeded this is more likely a RTP transport issue, for 
example missing I frame or something like that.
Just to be clear: the other participants saw you, but you couldn’t see any of 
the other participants?

Can you still go back to about:webrtc  and check what the RTP 
stats tell you in regards to receiving RTP?
What Firefox version and OS are you on?

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

Re: Enabling Silence Suppression in Firefox

[Nils Ohlmeier]

Hi Kannan,

> On May 3, 2017, at 14:18, Kannan Murali  wrote:
> 
> Anyway, I will file a bug in Bugzilla as you suggested.

Great. Let us know the bug number so we can ensure it categorized properly.

> Note: When we negotiate the same (maxaveragebitrate=24000; usedtx=1 and CN 
> attribute in SDP), with Chrome, it only sends a SID packet (I assume) every 
> 400ms as per standard. That way we save considerable bandwidth.

After talking to our Opus experts and briefly checking our code base I think it 
should be pretty easy to ad support for usedtx=1 for the Opus codec.
I would see that as a separate issue then enabling CN for the G.711 codecs.

Best
  Nils Ohlmeier

> 
> -KMurali
> 
> On Tuesday, May 2, 2017 at 1:55:48 PM UTC-7, Kannan Murali wrote:
>> Hi:
>> 
>> I have a Firefox WebRTC based client as part of our WebRTC conferencing 
>> solution and I am trying to enable the Silence Suppression feature in my 
>> Firefox WebRTC client.
>> 
>> I am triggering the SDP offer from Firefox WebRTC client, and was expecting 
>> the it to send (negotiate in the offer) CN payload in the m= line in the SDP 
>> offer.
>> 
>> However, I don't see the CN payload negotiated from Firefox and not sure how 
>> to enable the Silence Suppression feature. My intention was to reduce the 
>> bandwidth when there the mic is muted. I do see regular audio packets comes 
>> out of Firefox when the mic is muted.
>> 
>> Does anyone know how to enable the Silence Suppression in Firefox?
>> 
>> -KMurali
> 
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Enabling Silence Suppression in Firefox

[Nils Ohlmeier]

> On May 3, 2017, at 05:36, Randell Jesup  wrote:
> 
> We have never enabled silence suppression in Firefox.  We've had no (before 
> this) requests to do so, and my previous experience had been that CN support 
> in SIP Video calls was that CN was noticeable and mildly annoying at times, 
> and the bandwidth savings were minimal (I was using iLBC @ ~13Kbps).  
> However, that was a long time ago, so we could consider it (we're using more 
> bandwidth (much better audio), though bandwidth is also more available than 
> 10 years ago).


Actually RFC 7587 discourages the usage of CN in combination with Opus (section 
3.1.3), because Opus has a comfort noise generator build in.
So if at all we should only enable it for G.* codecs.

Kannnan which codec do you use?

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

Re: Firefox media port range

[Nils Ohlmeier]

For UDP there is non. We ask the OS for 0 and take what ever we get back.
For TCP we limit the ports to >= 49152.
We have an open bug which asks for an option to limit the port range 
https://bugzilla.mozilla.org/show_bug.cgi?id=1100121 


> On Apr 19, 2017, at 03:26, Alexander Abagian  wrote:
> 
> At least, what is the current port limit if any ?
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: ICE pairing and IP-v6 candidates

[Nils Ohlmeier]

Hi Alexander,

I don’t think that the candidate type should cause any confusion. In case of 
UDP the type actually does not really matter that much for the pairing.
If the over all ICE connection state never went to either succeed or failed in 
30min then that is clearly a bug we should look into.

To answer some of your earlier questions:
- no we don’t have an option to turn off IPv6
- I think there might a limit of the amount of pairs, but I think that is at 
100 pairs or something like that, so you should be far away from that
- I don’t know what you mean by “white-gray-IP pairs”

As Byron indicated earlier already a copy of your the ICE log from about:webrtc 
 would be the first step for taking a closer look into this.

Best
  Nils Ohlmeier

> On Apr 21, 2017, at 05:42, Alexander Abagian  wrote:
> 
> I guess server candidates 212.24.35.119:8001 and 212.24.35.119:8001 type was 
> mistakenly defined by the server as "host" and this could confuse ICE engine. 
> But anyway in this case checking state should not be kept "inprogress" for 
> such a long period (30 min or more).
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: single codec in answer rtpmap

[Nils Ohlmeier]

> On Mar 22, 2017, at 10:01, Alexander Abagian  wrote:
> 
> In Firefox, answer SDP rtpmap always includes no more than a one codec 
> descrption. Why doesn't it lists all corresponding codecs as Chrome does ?

Because it means that the answerer is willing to receive any of the listed 
codec at any time without renegotiating. And Firefox is simply not yet able to 
do that.

> Is there a way to overcome it without re-negotiation ?

Even a renegotiation won’t get you multiple codecs. A renegotiation allows you 
to switch to a different codec though.

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

Re: audio stream with unlisted in SDP ssrc is audible

[Nils Ohlmeier]

Hi Alexander,

> On Mar 20, 2017, at 11:53, Alexander Abagian  wrote:
> It illustrates that there's no inboundrtp SSRC, which is successfully 
> receiving and producing sound, in any of the remote m-sections.

Just to be super clear: audio is working in the example you gave, correct?

As Ekr pointed out SSRC’s are not required. So no SSRC in the SDP is not a bug.

If you are pointing out that for the case where there is no remote SSRC (with 
working audio) Firefox does not show that RTP stream in the stats that might 
actually be bug worth fixing on our end.

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

Re: audio stream with unlisted in SDP ssrc is audible

[Nils Ohlmeier]

On Mar 17, 2017, at 08:17, Alexander Abagian  wrote:
> 
> here's complete log
> 
> https://yadi.sk/d/ehbdA8Vy3G6nNr <https://yadi.sk/d/ehbdA8Vy3G6nNr>

This appears to contain some form of webrtc internals page. But that would be 
Chrome and not Firefox.

Additionally the SDP in your previous email is not the SDP from Firefox either.

Did you post this accidentally on the wrong list? :-)

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

Re: WebRTC over TCP support on Firefox

[Nils Ohlmeier]

Hello,

> On Feb 10, 2017, at 14:02, gauravh...@gmail.com wrote:
> Can you please confirm if Firefox is/will be supporting WebRTC over TCP? As 
> we are developing video streaming over webRTC this feature would be much 
> needed, this is currently available on Chrome but not on firefox. UDP is 
> available on FF however its blocked with several corporates due to firewall 
> port blocking issues.

Firefox supports already TURN over TCP. So if you have TURN server outside of 
the corporate network which offers its relay service via TCP that should work 
already.

If you are referring to ICE TCP that is being tracked in bug 1176382. It has 
been implemented for quite some time now and should work as long as 
multi-process support is off (check about:support ). The last 
pieces needed for ICE TCP to also work with multi-process landed in Firefox 53. 
You can give it a try if you manually switch the user pref 
media.peerconnection.ice.tcp on about:config  to true and restart 
your browser.
If you prefer to wait we are about to turn ICE TCP on by default in Firefox 54, 
which is being tracked in bug 1335939.

Best regards
  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

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

[Nils Ohlmeier]

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

Re: Limit of sending clients count

[Nils Ohlmeier]

Hi Alexander,

> On Nov 23, 2016, at 08:55, Alexander Abagian  wrote:
> 
> We've made a WebRTC load testing js app, starting a set of WebRTC clients in 
> a single page. Each of them has it's own RTCPeerConnection and everything 
> other. 
> 
> When it starts from Firefox, then only 15 of these clients become connected. 
> Any extra clients are dead. 
> 
> It looks like there is some limitation for ICE entities. Could you point me 
> the way to look at ?

I look at it from the point that Firefox was and is not designed to be (ab-) 
used as a load testing tool/client.

15 PeerConnections would be a really big conference call and you probably hit 
all kind of internal limitations.
If you are serious about building a WebRTC load testing tool I would recommend 
you to not do it in JS, but instead build your own client in C++ or something 
like that.

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

Re: degradationPreference seems to be not working

[Nils Ohlmeier]

> On Nov 15, 2016, at 11:30, Alexander Abagian  wrote:
> Trying to make a workaround for TIAS bandwidth control problem,…

What is that problem exactly?

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

Re: No DTLS alert on PeerConnection.close()?

[Nils Ohlmeier]

Lorenzo I create bug 1303867 to track and discuss this.

  Nils

> On Sep 19, 2016, at 12:53, Nils Ohlmeier  wrote:
> 
> A security bug around this behavior (which is not disclosed to the public 
> yet) has been fixed and uplifted to 48, which probably causes this new 
> behavior.
> 
>  Nils
> 
>> On Sep 19, 2016, at 02:22, Lorenzo Miniero  wrote:
>> 
>> Il giorno lunedì 19 settembre 2016 11:18:52 UTC+2, Martin Thomson ha scritto:
>>> No good info on the bug, which seems plausible.  I do have an
>>> observation though:
>>> 
>>> You can't rely on DTLS alerts arriving, since they are not
>>> retransmitted.  You should use signaling for session termination.
>>> 
>> 
>> 
>> Hi Martin,
>> 
>> yep, you're right, and in some modules we're already doing this, although 
>> it's not happening in this case which is what made the bug pop up.
>> 
>> Thanks,
>> Lorenzo
>> 
>> 
>>> On Mon, Sep 19, 2016 at 6:44 PM, Lorenzo Miniero  wrote:
>>>> Hi,
>>>> 
>>>> I've noticed a weird behaviour that seems to have started happening with 
>>>> Firefox 48, and is apparently happening with the latest Nightly as well. 
>>>> It looks like Firefox is not sending a DTLS alert anymore when a 
>>>> PeerConnection is closed. You can test this easily by opening this web 
>>>> page in a couple of tabs:
>>>> 
>>>> https://janus.conf.meetecho.com/videocalltest.html
>>>> 
>>>> This is a demo of a WebRTC call with media going through my WebRTC server. 
>>>> To replicate the issue, just choose two different usernames and have one 
>>>> call the other, and then have one of the two hangup. This will result, for 
>>>> both users, in a call to the PeerConnection.close(), and about:webrtc 
>>>> confirms both PCs are indeed closed, but looking at the traffic via 
>>>> Wireshark/tcpdump no DTLS alert is sent to the server by either of them. 
>>>> This makes the server actually unaware of the PC being closed.
>>>> 
>>>> Is this a known issue?
>>>> 
>>>> Thanks!
>>>> Lorenzo
>>>> ___
>>>> dev-media mailing list
>>>> dev-media@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-media
>> 
>> ___
>> dev-media mailing list
>> dev-media@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-media
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: No DTLS alert on PeerConnection.close()?

[Nils Ohlmeier]

A security bug around this behavior (which is not disclosed to the public yet) 
has been fixed and uplifted to 48, which probably causes this new behavior.

  Nils

> On Sep 19, 2016, at 02:22, Lorenzo Miniero  wrote:
> 
> Il giorno lunedì 19 settembre 2016 11:18:52 UTC+2, Martin Thomson ha scritto:
>> No good info on the bug, which seems plausible.  I do have an
>> observation though:
>> 
>> You can't rely on DTLS alerts arriving, since they are not
>> retransmitted.  You should use signaling for session termination.
>> 
> 
> 
> Hi Martin,
> 
> yep, you're right, and in some modules we're already doing this, although 
> it's not happening in this case which is what made the bug pop up.
> 
> Thanks,
> Lorenzo
> 
> 
>> On Mon, Sep 19, 2016 at 6:44 PM, Lorenzo Miniero  wrote:
>>> Hi,
>>> 
>>> I've noticed a weird behaviour that seems to have started happening with 
>>> Firefox 48, and is apparently happening with the latest Nightly as well. It 
>>> looks like Firefox is not sending a DTLS alert anymore when a 
>>> PeerConnection is closed. You can test this easily by opening this web page 
>>> in a couple of tabs:
>>> 
>>> https://janus.conf.meetecho.com/videocalltest.html
>>> 
>>> This is a demo of a WebRTC call with media going through my WebRTC server. 
>>> To replicate the issue, just choose two different usernames and have one 
>>> call the other, and then have one of the two hangup. This will result, for 
>>> both users, in a call to the PeerConnection.close(), and about:webrtc 
>>> confirms both PCs are indeed closed, but looking at the traffic via 
>>> Wireshark/tcpdump no DTLS alert is sent to the server by either of them. 
>>> This makes the server actually unaware of the PC being closed.
>>> 
>>> Is this a known issue?
>>> 
>>> Thanks!
>>> Lorenzo
>>> ___
>>> dev-media mailing list
>>> dev-media@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-media
> 
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: DTLS fatal alert : illegal parameter

[Nils Ohlmeier]

Hi Alexander,

That indeed looks like a bug in Firefox. I’m pretty sure the DTLS server is not 
suppose to send anything while waiting for the initial Hello. I opened this bug 
report for your problem https://bugzilla.mozilla.org/show_bug.cgi?id=1299952
I was not able to reproduce the problem by simply letting the client not send 
the initial Hello. So something must be different in your setup.
If you could get the signaling log file like described here 
https://wiki.mozilla.org/Media/WebRTC/Logging#Signaling_.28SDP_offer.2Fanswer_handling.29
and attach it to the bug report that would be really helpful.

Thank you
  Nils Ohlmeier

> On Sep 1, 2016, at 12:28, Alexander Abagian  wrote:
> 
> Here's it. The line right after Alert is server Client Hello.
> 
> 9 16:10:02.130349 192.168.125.138 9001192.168.125.39  154 
> STUNBinding Request user: 9affe06b0002USER  50423
> 1216:10:02.132106 192.168.125.39  50423   192.168.125.138 82  
> STUNBinding Error Response error-code: 401 (Unauthorized) Unauthorized
>   9001
> 1616:10:02.256364 192.168.125.138 9001192.168.125.39  158 
> STUNBinding Request user: 9affe06b:0002USER 50423
> 2216:10:02.259959 192.168.125.39  50423   192.168.125.138 142 
> STUNBinding Request user: 0002USER:9affe06b 9001
> 2316:10:02.260247 192.168.125.39  50423   192.168.125.138 106 
> STUNBinding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 
>   9001
> 2416:10:02.260766 192.168.125.138 9001192.168.125.39  130 
> STUNBinding Success Response user: 0002USER:9affe06b XOR-MAPPED-ADDRESS: 
> 192.168.125.39:50423   50423
> 2816:10:02.812030 192.168.125.138 9001192.168.125.39  158 
> STUNBinding Request user: 9affe06b:0002USER 50423
> 3216:10:02.815013 192.168.125.39  50423   192.168.125.138 106 
> STUNBinding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 
>   9001
> 3316:10:02.859969 192.168.125.39  50423   192.168.125.138 57  
> DTLSv1.2Alert (Level: Fatal, Description: Illegal Parameter)9001
> 3416:10:03.060687 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 4616:10:03.774995 192.168.125.138 9001192.168.125.39  158 
> STUNBinding Request user: 9affe06b:0002USER 50423
> 4916:10:03.776711 192.168.125.39  50423   192.168.125.138 106 
> STUNBinding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 
>   9001
> 5016:10:05.002177 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 5116:10:09.001930 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 5216:10:16.992382 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 5316:10:32.971012 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 
> 
> On Thursday, September 1, 2016 at 9:01:11 PM UTC+3, Nils Ohlmeier wrote:
>>> On Sep 1, 2016, at 04:51, Alexander Abagian wrote:
>>> 
>>> Here's webrtc-internals. The pcap is almost the same, the only difference 
>>> is some 5-digit ports. Firefox ip is 192.168.125.39. Media server 
>>> (192.168.125.138) is offerer, and acts as a DTLS client.
>> 
>> Well in case of your media server being the DTLS client my next question is: 
>> can you add the ICE packets for the video port to your Wireshark trace?
>> And did your media server actually send any DTLS client hello to Firefox?
>> 
>> It is possible that this is some kind of bug in Firefox as we don’t have 
>> that many implementations which use on purpose two bundle sets.
>> 
>> Best regards
>>  Nils Ohlmeier
> 
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: DTLS fatal alert : illegal parameter

[Nils Ohlmeier]

> On Sep 1, 2016, at 04:51, Alexander Abagian  wrote:
> 
> Here's webrtc-internals. The pcap is almost the same, the only difference is 
> some 5-digit ports. Firefox ip is 192.168.125.39. Media server 
> (192.168.125.138) is offerer, and acts as a DTLS client.

Well in case of your media server being the DTLS client my next question is: 
can you add the ICE packets for the video port to your Wireshark trace?
And did your media server actually send any DTLS client hello to Firefox?

It is possible that this is some kind of bug in Firefox as we don’t have that 
many implementations which use on purpose two bundle sets.

Best regards
  Nils Ohlmeier


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: DTLS fatal alert : illegal parameter

[Nils Ohlmeier]

Hi Alexander,

I think we would need to see the SDP for the matching call. The SDP should tell 
you which side of the call got negotiated as the DTLS server and client.
Which version of Firefox do you see this problem with?

Looking at our code briefly it potentially could be that Firefox does send such 
an Alert in case it is the DTLS server and never receives a Client Hello.

Best regards
  Nils Ohlmeier

> On Aug 31, 2016, at 11:58, Alexander Abagian  wrote:
> 
> Hi all,
> 
> In random cases, when Firefox webrtc client connects to the media server, I'm 
> getting a DTLS handshake for the video channel (only) fails with DTLS v1.2 
> alert "illegal parameter". What is strange, that this alert is the first DTLS 
> message in the whole DTLS handshake session; and never appears in audio 
> channel (we use separate audio and video connections).
> 
> RFC tells :
> 
> illegal_parameter
>  A field in the handshake was out of range or inconsistent with
>  other fields.  This message is always fatal.
> 
> But the alert message is the first one ! Could it be a reaction not to a 
> incoming DTLS, but to a wrong DTLS-related configurations in Firefox SDP ?
> 
> The server uses DTLS v1.0.
> 
> Wireshark log:
> filter: ip.addr == 192.168.125.138 && dtls
> 
> 5202  16:10:02.859969 192.168.125.39  50423   192.168.125.138 57  
> DTLSv1.2Alert (Level: Fatal, Description: Illegal Parameter)9001
> 5223  16:10:03.060687 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 5255  16:10:03.353462 192.168.125.138 8001192.168.125.39  263 
> DTLSv1.0Client Hello52713
> 5259  16:10:03.357654 192.168.125.39  52713   192.168.125.138 681 
> DTLSv1.0Server Hello, Certificate, Server Key Exchange, Certificate 
> Request, Server Hello Done  8001
> 5262  16:10:03.383612 192.168.125.138 8001192.168.125.39  298 
> DTLSv1.0Certificate (Fragment)  52713
> 5263  16:10:03.391366 192.168.125.138 8001192.168.125.39  298 
> DTLSv1.0Certificate (Reassembled), Client Key Exchange (Fragment) 
>   52713
> 5265  16:10:03.497471 192.168.125.138 8001192.168.125.39  278 
> DTLSv1.0Client Key Exchange (Reassembled), Certificate Verify   52713
> 5266  16:10:03.497691 192.168.125.138 8001192.168.125.39  133 
> DTLSv1.0Change Cipher Spec, Encrypted Handshake Message 52713
> 5273  16:10:03.502496 192.168.125.39  52713   192.168.125.138 133 
> DTLSv1.0Change Cipher Spec, Encrypted Handshake Message 8001
> 5485  16:10:05.002177 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 6012  16:10:09.001930 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 6928  16:10:16.992382 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> 8791  16:10:32.971012 192.168.125.138 9001192.168.125.39  263 
> DTLSv1.0Client Hello50423
> ___
> dev-media mailing list
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: bogus candidates

[Nils Ohlmeier]

> On Jul 25, 2016, at 02:24, Neernay Khairkar  wrote:
> 
> 
> Yes, the ICE is failing in this case. Below are the respective SDPs from 
> Chrome and FF.
> 
> SDP received by FF (from Chrome)
> 
> v=0
> o=Mavenir 027212273305673895 305673895 IN IP4 199.119.111.154
> s=Mavenir SDP
> c=IN IP4 199.119.111.154
> b=AS:81
> b=RS:1012
> b=RR:3037
> t=0 0
> a=ice-lite
> m=audio 14000 RTP/SAVPF 111
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=sendrecv
> a=rtcp-mux
> a=maxptime:60
> a=ssrc:3261391358 cname:a/024zSC1aeOLrrv
> a=ssrc:3261391358 msid:u94nxuw6IrYNw9q7QynfRHebMyZ5PnHsb2Cc 
> e1ca310e-198a-46e5-97a1-c169c5829ea5
> a=ssrc:3261391358 mslabel:u94nxuw6IrYNw9q7QynfRHebMyZ5PnHsb2Cc
> a=ssrc:3261391358 label:e1ca310e-198a-46e5-97a1-c169c5829ea5
> a=ptime:20
> a=ice-ufrag:zJvm
> a=ice-pwd:zJvmHwvGDDwjhUGMpBVICw
> a=fingerprint:sha-256 
> D3:20:F6:20:ED:92:8F:08:52:C9:E9:21:ED:A9:7D:DE:16:F2:1D:6B:24:C4:85:C7:22:5D:F7:89:14:84:62:E1
> a=setup:actpass
> a=candidate:1 1 UDP 2130706431 199.119.111.154 14000 typ host
> a=candidate:1 2 UDP 2130706430 199.119.111.154 14001 typ host
> a=msi:mavodi-0-14c-b-2--@10.7.1.108
> a=rtpmap:111 opus/48000/2
> a=fmtp:111 minptime=10;useinbandfec=1
> 
> SDP generated by FF (for Chrome):
> 
> v=0
> o=- 5101797779164919864 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=group:BUNDLE audio
> a=msid-semantic: WMS u94nxuw6IrYNw9q7QynfRHebMyZ5PnHsb2Cc
> m=audio 2734 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
> c=IN IP4 27.50.5.103
> a=rtcp:2711 IN IP4 27.50.5.103
> a=candidate:797797419 1 udp 2122260223 172.18.42.61 62543 typ host generation > 0
> a=candidate:797797419 2 udp 2122260222 172.18.42.61 62544 typ host generation > 0
> a=candidate:3650950655 2 udp 1686052606 27.50.5.103 2711 typ srflx raddr 
> 172.18.42.61 rport 62544 generation 0
> a=candidate:1628344539 1 tcp 1518280447 172.18.42.61 0 typ host tcptype 
> active generation 0
> a=candidate:1628344539 2 tcp 1518280446 172.18.42.61 0 typ host tcptype 
> active generation 0
> a=candidate:3650950655 1 udp 1686052607 27.50.5.103 2734 typ srflx raddr 
> 172.18.42.61 rport 62543 generation 0
> a=ice-ufrag:G8NS7EGUITHiDDT5
> a=ice-pwd:K+AZztgmgZlKnLNnZR0qsIVZ
> a=fingerprint:sha-256 
> 49:39:23:7D:1B:02:1C:6C:C5:15:C2:D2:79:E8:D6:5C:2F:BC:1C:89:73:CC:3E:AB:1C:88:E5:23:EB:D5:45:CF
> a=setup:actpass
> a=mid:audio
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=sendrecv
> a=rtcp-mux
> a=rtpmap:111 opus/48000/2
> a=fmtp:111 minptime=10; useinbandfec=1
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:106 CN/32000
> a=rtpmap:105 CN/16000
> a=rtpmap:13 CN/8000
> a=rtpmap:126 telephone-event/8000
> a=maxptime:60
> a=ssrc:3261391358 cname:a/024zSC1aeOLrrv
> a=ssrc:3261391358 msid:u94nxuw6IrYNw9q7QynfRHebMyZ5PnHsb2Cc 
> e1ca310e-198a-46e5-97a1-c169c5829ea5
> a=ssrc:3261391358 mslabel:u94nxuw6IrYNw9q7QynfRHebMyZ5PnHsb2Cc
> a=ssrc:3261391358 label:e1ca310e-198a-46e5-97a1-c169c5829ea5

This SDP is generated by Chrome, not by Firefox.

But in any case I would recommend you to open a bug report on 
https://bugzilla.mozillla.org and attach a copy of ‘about:webrtc' together with 
your report. And if you let us know about the bug report number here we can 
quickly make sure the bug is in the right category so it stays on our radar.

Best regards
  Nils Ohlmeier



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: bogus candidates

[Nils Ohlmeier]

> On Jul 22, 2016, at 02:52, nskhair...@gmail.com wrote:
> 
> Hi, Is there any work around for this error?
> I am also getting the same issue when trying to call FF from Chrome.
> 
>  (ice/ERR) ICE(PC:1469173555764000 (id=2147483755 
> url=http://172.16.120.203/mbsclient/subodh/#/call)): peer 
> (PC:1469173555764000 (id=2147483755 
> url=http://172.16.120.203/mbsclient/subodh/#/call):default) specified too 
> many components
> 
> (ice/WARNING) ICE(PC:1469173555764000 (id=2147483755 
> url=http://172.16.120.203/mbsclient/subodh/#/call)): peer 
> (PC:1469173555764000 (id=2147483755 
> url=http://172.16.120.203/mbsclient/subodh/#/call):default) specified bogus 
> candidate

Hard to say without seeing the actual candidate and the SDP involved. But 
basically the error message indicates that the ICE candidate you pass in refers 
to a component which from FF perspective does not exist in the SDP.

Best
  Nils


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Please help

[Nils Ohlmeier]

Hi Benjamin,

I replied to Muly outside of this list with suggestions and questions.

Best
  Nils

> On Jul 18, 2016, at 04:45, Benjamin Moor  wrote:
> 
> Hi,
> 
> Hope you can help me with the serious issues we have with FF.
> 
> Testing webrtc video we seem to have a major performance issue with Firefox 
> which we are not sure why.
> 
> 
> 
> Here the results we get
> 
> 
> 
> 
> Service Setup
> 
> OS
> 
> FF
> 
> Audio Bit Rate
> 
> Video Bit Rate
> 
> Video FPS
> 
> 
> Browserstack
> 
> OS X Mavericks (v 10.9)
> 
> 46
> 
> 50
> 
> 930
> 
> 30
> 
> 
> Win 7
> 
> 46
> 
> 49
> 
> 940
> 
> 30
> 
> 
> Win XP
> 
> 46
> 
> 50
> 
> 950
> 
> 30
> 
> 
> Win 10
> 
> 46
> 
> 49
> 
> 900
> 
> 26
> 
> 
> 
> Docker
> 
> Linux
> 
> 46
> 
> 4
> 
> 450
> 
> 1
> 
> 
> Baremetal
> 
> 8core
> 
> Linux
> 
> 46
> 
> 16
> 
> 592
> 
> 9
> 
> 
> Azure VM
> 
> Windows 2012
> 
> 46
> 
> 8
> 
> 352
> 
> 5
> 
> 
> 
> Some background about the setup
> 
> 1.We open AppRTC webrtc page
> 2.Add hidden video element to the page and load a VGA webm video from CDN
> 3.we capture stream from video using HTMLMediaElement.mozCaptureStream() 
> and use this stream as fake input for getUserMedia
> 4.As far as we see from the SDP the codec used is VP8
> 
> On our main setup Linux on Docker, the video get play in 1fps,
> 
> running without docker Linux or Window strong cloud machines give us 9/5 fps
> 
> 
> 
> Not sure why but same on BrowserStack OSX and Windows machine show much 
> better results but still cannot run HD size video and reach our Docker+Chrome 
> setup which has no problem to run HD.
> 
> 
> 
> Any hint will be highly appreciated.
> 
> THANK you,
> 
> Benjamin
> 
> 
> 
> From: Romain Testard [mailto:rom...@mozilla.com]
> Sent: Tuesday, January 5, 2016 3:33 PM
> To: Benjamin Moor
> Subject: Re: HAVE A GREAT 2016!
> 
> 
> 
> Hi Benjamin,
> 
> 
> 
> Best wishes for 2016 and congrats for the quick adoption of testRTC in the 
> industry, pretty impressive!
> 
> Within the Firefox Hello team we still have no need for testing/monitoring 
> help although I'll be sure to contact you if we identify areas where you may 
> be able to bring value.
> 
> 
> 
> Thanks,
> 
> Romain
> 
> 
> 
> On Sun, Dec 27, 2015 at 2:51 PM, Benjamin Moor  wrote:
> 
> Romain,
> 
> 
> 
> I wish you and your family a GREAT 2016!
> 
> 
> 
> 6 months from our last communication. Below our communication from July.
> 
> 
> 
> testRTC developed dramatically in those 6 months.
> 
> We got a GA product with large scale functionality for testing. We added 
> monitoring functionality. We have today more than 20 customers in production. 
> We grow on average 6 clients per Q. Partial list of our clients: GENDBAND, 
> ATT, TELEFONICA, VIDYO, AVAYA more.
> 
> 
> 
> Do Mozila have a need for webRTC testing and monitoring?
> 
> I’ll try calling you right after your holidays.
> 
> 
> 
> 
> 
> BR,
> 
> 
> 
> Benjamin
> 
> CEO/ Co-Founder
> 
> Inline image 1
> 
> 
> 
> 
> 
> 
> 
> From: Romain Testard [mailto:rom...@mozilla.com]
> Sent: Friday, July 24, 2015 5:54 PM
> To: Benjamin Moor
> Subject: Re: meeting in Paris?
> 
> 
> 
> Hi Benjamin,
> 
> 
> 
> I don't think there is a real good fit for Hello (we already have 
> testing/monitoring in place and we operate in a fairly specific mode which 
> probably means your tools would have to be highly customized to fit what we 
> do - we're built in the browser as opposed to operating on a web page always).
> 
> That said how about we have a 30 min chat to go through your solution so I 
> get a better understanding of what it allows, I can update you on the latest 
> with Hello and also maybe you have feedback at the Firefox WebRTC level that 
> you'd like to raise in order to make you testing solution better?
> 
> 
> 
> I'm in France next week so if you're in Israel we can probably chat in the 
> morning - how about Tuesday morning?
> 
> 
> 
> Thanks,
> 
> Romain
> 
> 
> 
> 
> 
> On Thu, Jul 23, 2015 at 5:57 PM, Benjamin Moor  wrote:
> 
> Romain, any good news such as we can demonstrate our solution to relevant 
> team ? J
> 
> Let’s talk in the coming week.
> 
> 
> 
> BR,
> 
> Benjamin
> 
> 
> 
> 
> 
> From: Romain Testard [mailto:rom...@mozilla.com]
> Sent: Wednesday, July 15, 2015 6:10 PM
> To: Benjamin Moor
> Subject: Re: meeting in Paris?
> 
> 
> 
> Hi Benjamin,
> 
> 
> 
> Thanks for reaching out.
> 
> I am actually home based in Lyon.
> 
> Per my other e-mail please give me a couple of days to catch-up on stuff and 
> get ideas from the team to see if there is value for us there.
> 
> 
> 
> 
> 
> Thanks!
> 
> Romain
> 
> 
> 
> On Wed, Jul 15, 2015 at 4:22 PM, Benjamin Moor  wrote:
> 
> Romain,
> 
> 
> 
> I will be in Paris next Thursday July 23 for few days.
> 
> Would it be possible to meet and try to explore if our product will have 
> added value for your work?
> 
> 
> 
> Have a great day!
> 
> Benjamin
> 
> 
> 
> On Sat, Jul 4, 2015 at 1:54 PM, Romain Testard  wrote:
> 
> Name: Romain Testard
> Email: rom...@mo

Re: ICE connection breaks after deleting a participant

[Nils Ohlmeier]

Hi Alexander,

The new offer makes the m-sections inactive which Firefox used for the bundled 
ICE transport. I can imagine that this causes Firefox ICE stack to think that 
it needs to negotiate new ICE candidates. But that would be a bug as we should 
be able to keep using the existing bundled ICE connection. Can you please file 
a bug on bugzilla.mozilla.org for this?

> On May 30, 2016, at 21:13, Alexander Abagian  wrote:
> 
> Hi,
> 
> I have the following case.
> 
> There's a conference with a three participants. One of them quits, and after 
> that ICE connection becomes broken.
> Each m-section uses its own mid, audio and video are multistreamed in two 
> transport channels.
> 
> The order is always SetRemoteDescription["offer"] / 
> SetLocalDescription["answer"].
> 
> To delete the participant, I'm using "a=inactive" attributes, adding them to 
> m=audio and m=video sections.
> After that I see in Local SDP that m-sections concerning to Remote SDP 
> sections are also inactive - it's OK -
> but other Local SDP sections reflecting still alive third participant by some 
> reason becomes "recvonly",
> onicecandidate() callbacks are fired, and ICE connection dissapears (SFU is 
> not awaiting for ICE reconnection).
> 
> How to disable this re-ICEing ?
> 
> 
> 
> 
> 
> ---
> Three participants now
> 
 Remote sdp 1, type = offer
> v=0
> o=- 31464631288080 2 IN IP4 192.67.4.14
> s=-
> t=0 0
> a=group:BUNDLE audio-2775104712 audio-3601440349
> a=group:BUNDLE video-3855279324 video-1544371678
> a=ice-options:trickle
> a=msid-semantic: WMS *
> 
> m=audio 1 RTP/SAVPF 102 18 15 9 117 116 115 114 99 96 113 112 8 0 124 125
> c=IN IP4 192.168.125.117
> b=AS:50
> a=mid:audio-2775104712
> a=msid:MSID-1-5306(u.vm)@deb7-abagyan.mambetcorp.com-2775104712 
> MSTID-AUDIO-2775104712 MSID-CqI0IQlUSXZ7hcFH-2775104712-
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:0005USER
> a=ice-pwd:0005CALLIDABCDEFGHIJKLMNPASSWORD
> a=end-of-candidates
> a=sendrecv
> a=rtcp-mux
> a=fingerprint:sha-256 
> F4:62:26:0F:66:C8:94:71:5A:9C:E9:0D:E1:D4:81:9C:82:A1:9B:13:BF:0A:6E:73:E7:24:1E:3C:FC:5E:70:CB
> a=rtpmap:9 G722/8000
> a=fmtp:9 bitrate=64000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=ssrc:2775104712 cname:CqI0IQlUSXZ7hcFH
> a=setup:active
> 
> m=video 1 RTP/SAVPF 109 100 46 40 124 125
> c=IN IP4 192.168.125.117
> b=AS:500
> a=mid:video-3855279324
> a=msid:MSID-1-5306(u.vm)@deb7-abagyan.mambetcorp.com-3855279324 
> MSTID-VIDEO-3855279324 MSID-CqI0IQlUSXZ7hcFH-3855279324-
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:0005USER
> a=ice-pwd:0005CALLIDABCDEFGHIJKLMNPASSWORD
> a=end-of-candidates
> a=sendrecv
> a=rtcp-mux
> a=fingerprint:sha-256 
> F4:62:26:0F:66:C8:94:71:5A:9C:E9:0D:E1:D4:81:9C:82:A1:9B:13:BF:0A:6E:73:E7:24:1E:3C:FC:5E:70:CB
> a=rtpmap:109 H264-SVC/9
> a=rtpmap:100 VP8/9
> a=rtcp-fb:100 ccm fir
> a=rtcp-fb:100 nack
> a=rtcp-fb:100 nack pli
> a=rtpmap:46 VP8-SVC/9
> a=rtpmap:40 H263-1998/9
> a=ssrc:3855279324 cname:CqI0IQlUSXZ7hcFH
> a=setup:active
> 
> m=audio 1 RTP/SAVPF 102 18 15 9 117 116 115 114 99 96 113 112 8 0 124 125
> c=IN IP4 192.168.125.117
> b=AS:50
> a=mid:audio-3601440349
> a=msid:MSID-admin(u.vm)@deb7-abagyan.mambetcorp.com-3601440349 
> MSTID-AUDIO-3601440349 MSID-xM06DtEznzfbpQLm-3601440349-
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:0005USER
> a=ice-pwd:0005CALLIDABCDEFGHIJKLMNPASSWORD
> a=end-of-candidates
> a=sendrecv
> a=rtcp-mux
> a=fingerprint:sha-256 
> F4:62:26:0F:66:C8:94:71:5A:9C:E9:0D:E1:D4:81:9C:82:A1:9B:13:BF:0A:6E:73:E7:24:1E:3C:FC:5E:70:CB
> a=rtpmap:9 G722/8000
> a=fmtp:9 bitrate=64000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=ssrc:3601440349 cname:xM06DtEznzfbpQLm
> a=setup:active
> 
> m=video 1 RTP/SAVPF 109 100 46 40 124 125
> c=IN IP4 192.168.125.117
> b=AS:500
> a=mid:video-1544371678
> a=msid:MSID-admin(u.vm)@deb7-abagyan.mambetcorp.com-1544371678 
> MSTID-VIDEO-1544371678 MSID-xM06DtEznzfbpQLm-1544371678-
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:0005USER
> a=ice-pwd:0005CALLIDABCDEFGHIJKLMNPASSWORD
> a=end-of-candidates
> a=sendrecv
> a=rtcp-mux
> a=fingerprint:sha-256 
> F4:62:26:0F:66:C8:94:71:5A:9C:E9:0D:E1:D4:81:9C:82:A1:9B:13:BF:0A:6E:73:E7:24:1E:3C:FC:5E:70:CB
> a=rtpmap:109 H264-SVC/9
> a=rtpmap:100 VP8/9
> a=rtcp-fb:100 ccm fir
> a=rtcp-fb:100 nack
> a=rtcp-fb:100 nack pli
> a=rtpmap:46 VP8-SVC/9
> a=rtpmap:40 H263-1998/9
> a=ssrc:1544371678 cname:xM06DtEznzfbpQLm
> a=setup:active
> 
> onsignalingstatechange signalingstatechange { target: mozRTCPeerConnection, 
> isTrusted: true, currentTarget: mozRTCPeerConnection, eventPhase: 2, bubbles: 
> false, cancelable: false, defaultPrevented: false, timeStamp: 
> 1464631288114000, originalTarget: mozRTCPeerConnection, 
> explicitOriginalTarget: mozRTCPeerConnection, NONE: 0 } wrtc.js:348:13
> remoteDescription happy wrtc.js:805:17
> 
> 
> --

Re: ICE Failure with Firefox 45

[Nils Ohlmeier]

> On Apr 13, 2016, at 17:39, Kannan Murali  wrote:
> 
> I have upload the following items (about:webrtc capture after the test,
> WebRTC client side logs which includes out application logs also, the 
> Wireshark capture during the test and the Janus GW logs with ice debug 
> enabled) for both FF43 and FF45:
> 
> For FF45(Not Working Case):
> aboutWebrtc_FF45_ICE_Issue_04_13_2016.html
> FF45_WebRTC_Client_ICE_Issue_Log_04_13_2016.txt
> FF45_WebRTC_Client_ICE_Issue_04_13_2016.pcapng
> janus_GW_FF45_ICE_Issue_04_13_2016.log
> 
> For FF43(Working Case):
> aboutWebrtc_FF43_ICE_Working_04_13_2016.html
> FF43_WebRTC_Client_ICE_working_Log_04_13_2016.txt
> FF43_WebRTC_Client_ICE_Working_04_13_2016.pcapng
> janus_GW_FF43_ICE_Working_04_13_2016.log

Sounds like you had files attached to your email. But the email attachments 
were removed by the email list server. So we can’t look at them any more. As 
Byron replied already: if you open a bug report and attach the same log files 
then we can have a look at them. It might be helpful to post your bug report 
number here on the list in case your bug report lands in a Bugzilla category 
where we don’t see/notice it.

Best regards
  Nils Ohlmeier



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox cannot act as DHE server

[Nils Ohlmeier]

Hi Ors,

> On Mar 10, 2016, at 09:12, ors.szabo...@gmail.com wrote:
> I'm getting DTLS handshake failure basically with all FF versions (even with 
> latest nightly build) for a DTLS client hello with the following cipher 
> suites:
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
> 
> Is this a known fault in FF?

Have you read this hack post already?
https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrecy-pfs-starting-in-firefox-38/

Best regards
  Nils Ohlmeier


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: TCP Turn Relay

[Nils Ohlmeier]

> On Feb 29, 2016, at 04:23, Balwant Bisht  wrote:
> 
> TCP turn via proxy work in Firefox?
> 
> I am trying to establish webrtc call via Turn's TCP port 443 and user is 
> behind proxy server which require authentication. But firefox not trying to 
> connect to turn server on port 443. I tried on Firefox Nightly 47.0a1 
> (2016-02-28) and enabled "media.peerconnection.ice.tcp"

The ICE TCP pref which you set has nothing to do with TURN TCP via HTTP 
proxies. For ICE TCP the same restriction applies: it does not work yet with 
e10s turned on. That is actively being worked on.

Firefox supports TURN TCP through a HTTP proxy. But we don’t support proxy 
authentication.

Regards
  Nils Ohlmeier



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: No STUN servers specified on FF33

[Nils Ohlmeier]

I'm assuming the topmost call is the problematic one: Your local SDP 
does not show even any host candidates.
Does your service live.amaryllo.eu support trickle ICE at all? E.g. does 
you code listen on the onicedandidate event?


  Nils

On 12/3/14 6:07 PM, asla...@amaryllo.eu wrote:

Here is a full logging message 
(https://mega.co.nz/#!lNckgIwD!wFL9yXHbH-U79iaOYHp_MphuKol3-14tA_yRQokWylk)

Actually, I am very sure I had set STUN and TURN in every PeerConnection (I had 
checked this with debugging message). But it still doesn't work.


On Wednesday, December 3, 2014 11:40:05 PM UTC+8, Byron Campen wrote:

A couple of things. Firt, that logging is very misleading. It is
complaining that there are no STUN/TURN servers in the global config
store for nICEr. We configure STUN/TURN on a per-context basis, so we
don't actually configure them in the global store. Second, we are
planning on removing that default stun.services.mozilla.com sometime
this coming year. Don't count on it being around forever.

  Can you get us some logging for the failure you're seeing, and
perhaps a packet trace?

Best regards,
Byron Campen

On 12/2/14 11:53 PM, asla...@amaryllo.eu wrote:

Hi all,

Today, one thing is happened to me, not good. My FF33 can not connect to the 
other webrtc client anymore. I check about:webrtc, and find the following error 
message:

(ice/WARNING) ICE(PC:1417591976251000 (id=3291 
url=https://live.amaryllo.eu/#)): No STUN servers specified
(ice/NOTICE) ICE(PC:1417591976251000 (id=3291 url=https://live.amaryllo.eu/#)): 
No TURN servers specified

I think that the root cause in this issue. My question is.. FF33 has its 
default STUN Server (stun:stun.services.mozilla.com), why it will report me No 
STUN servers?

However, this case is not easy to reproduce, and it will work after restarting 
FF33. Anyone can help?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media



On Wednesday, December 3, 2014 11:40:05 PM UTC+8, Byron Campen wrote:

A couple of things. Firt, that logging is very misleading. It is
complaining that there are no STUN/TURN servers in the global config
store for nICEr. We configure STUN/TURN on a per-context basis, so we
don't actually configure them in the global store. Second, we are
planning on removing that default stun.services.mozilla.com sometime
this coming year. Don't count on it being around forever.

  Can you get us some logging for the failure you're seeing, and
perhaps a packet trace?

Best regards,
Byron Campen

On 12/2/14 11:53 PM, asla...@amaryllo.eu wrote:

Hi all,

Today, one thing is happened to me, not good. My FF33 can not connect to the 
other webrtc client anymore. I check about:webrtc, and find the following error 
message:

(ice/WARNING) ICE(PC:1417591976251000 (id=3291 
url=https://live.amaryllo.eu/#)): No STUN servers specified
(ice/NOTICE) ICE(PC:1417591976251000 (id=3291 url=https://live.amaryllo.eu/#)): 
No TURN servers specified

I think that the root cause in this issue. My question is.. FF33 has its 
default STUN Server (stun:stun.services.mozilla.com), why it will report me No 
STUN servers?

However, this case is not easy to reproduce, and it will work after restarting 
FF33. Anyone can help?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

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


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

Re: WebRTC connection success or failure dependant on who makes the offer?

[Nils Ohlmeier]

Firefox only allows you to add ice candidates after setRemoteDescription 
has been called. Maybe if you ensure that in your code it will solve 
some of the problems.


Best
  Nils Ohlmeier

On 11/15/14 7:07 AM, Mario Carbajal wrote:

I just did an experiment, I delayed the addIceCandidate calls in the
computer that makes the answer and that reversed success conditions.

This means that it's not dependent on who makes the answer or offer, but
dependent on the order in which the ice candidates are added.

On Fri, Nov 14, 2014 at 10:06 PM, Mario Carbajal 
wrote:
Yes, it does.

On Fri, Nov 14, 2014 at 9:58 PM, Eric Rescorla  wrote:


Can you confirm that it fails with two chromes and with two firefoxes?

On Fri, Nov 14, 2014 at 2:45 PM, Mario Carbajal 
wrote:


The signaling of my project being wrong was my first bet, but it seems to
happen everywhere.
http://webrtcdevelop.appspot.com/ and https://www.sharefest.me/ for
example.

On Fri, Nov 14, 2014 at 7:35 PM, Eric Rescorla  wrote:


It shouldn't matter. I wonder if something is going wrong with your
signaling
system. Which calling site are you using?

-Ekr


On Fri, Nov 14, 2014 at 10:56 AM,  wrote:


I have two computers trying to connect to each other with webrtc
(datachannel and STUN only).
Computer A with no NAT or firewall.
Computer B behind a router with NAT.
When A creates an offer and B the answer the connection is successful.
However, when B creates an offer and A creates the answer the

connection

fails.

Shouldn't the connection success/failure be independent of who makes

the

offer and who makes the answer?

If it's not independent, in order to maximize the chances of two users
being able to connect to each other webrtc applications would need to
attempt both combinations...

I've tested these two computers with many different webrtc apps, in

both

firefox and chrome, it's always the same result.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media




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




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


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

Re: Turn Server doesn't work if PC is under Airport WiFi AP

[Nils Ohlmeier]

Hi Aslan,

Neither the SDP nor the ICE candidates below are from Firefox. Firefox 
does not (yet) support Bundle or labels.

Did you just send us the wrong debug output?

Best
  Nils Ohlmeier

On 11/17/14 3:27 AM, asla...@amaryllo.eu wrote:

I find even the other peer doesn't receive candidates, it still can make 
connection in sometime. Why?

Here is SDP which FF sends to the device:
"v=0\r\no=- 8814186103337328720 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 
0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS ARDAMS\r\nm=audio 1 
RTP\/SAVPF 103 111 9 102 0 8 106 105 13 127 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN 
IP4 
0.0.0.0\r\na=ice-ufrag:64BzBMsOxdK6Aelk\r\na=ice-pwd:1qTE1U0TLydIjilff2CJjQmB\r\na=ice-options:google-ice\r\na=fingerprint:sha-1
 
F8:DA:30:1B:8C:3E:5B:1C:82:2E:D5:65:64:60:64:D0:C8:8E:99:06\r\na=setup:actpass\r\na=mid:audio\r\na=extmap:1
 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 
http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111
 opus\/48000\/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:103 ISAC\/16000\r\na=rtpmap:9 
G722\/16000\r\na=rtpmap:102 ILBC\/8000\r\na=rtpmap:0 PCMU\/8000\r\na=rtpmap:8 
PCMA\/8000\r\na=rtpmap:106 CN\/32000\r\na=rtpmap:105 CN\/16000\r\na=rtpmap:13 
CN\/8000\r\na=rtpmap:127 red\/8000\r\na=rtpmap:126 
telephone-event\/8000\r\na=maxptime:60\r\na=ssrc:120917423 cname:8c

pG

  2axRBu\/+9r\/Z\r\na=ssrc:120917423 msid:ARDAMS ARDAMSa0\r\na=ssrc:120917423 
mslabel:ARDAMS\r\na=ssrc:120917423 label:ARDAMSa0\r\nm=video 1 RTP\/SAVPF 98 
96\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 
0.0.0.0\r\na=ice-ufrag:64BzBMsOxdK6Aelk\r\na=ice-pwd:1qTE1U0TLydIjilff2CJjQmB\r\na=ice-options:google-ice\r\na=fingerprint:sha-1
 
F8:DA:30:1B:8C:3E:5B:1C:82:2E:D5:65:64:60:64:D0:C8:8E:99:06\r\na=setup:actpass\r\na=mid:video\r\na=extmap:2
 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 
http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:98
 H264\/9\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack 
pli\r\na=rtcp-fb:98 goog-remb\r\na=rtpmap:96 rtx\/9\r\na=fmtp:96 apt=98\r\n"

And also, the candidates which FF sends to the device:
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 1 udp 
2122194687 10.0.1.57 60258 typ host generation 0","label":0,"type":"candidate"}
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 2 udp 
2122194687 10.0.1.57 60258 typ host generation 0","label":0,"type":"candidate"}
{"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 1 udp 
2122194687 10.0.1.57 60258 typ host generation 0","label":1,"type":"candidate"}
{"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 2 udp 
2122194687 10.0.1.57 60258 typ host generation 0","label":1,"type":"candidate"}
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 1 tcp 1518214911 
10.0.1.57 60786 typ host tcptype passive generation 0","label":0,"type":"candidate"}
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 2 tcp 1518214911 
10.0.1.57 60786 typ host tcptype passive generation 0","label":0,"type":"candidate"}
{"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 1 tcp 1518214911 
10.0.1.57 60786 typ host tcptype passive generation 0","label":1,"type":"candidate"}
{"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 2 tcp 1518214911 
10.0.1.57 60786 typ host tcptype passive generation 0","label":1,"type":"candidate"}
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 1 udp 
1685987071 211.72.69.111 47994 typ srflx raddr 10.0.1.57 rport 60258 generation 0","label":0,"type":"candidate"}
{"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 2 udp 
1685987071 21

Re: Turn Server doesn't work if PC is under Airport WiFi AP

[Nils Ohlmeier]

On 11/11/14 10:06 AM, Randell Jesup wrote:

On 11/11/2014 11:45 AM, Byron Campen wrote:
 Do you get audio? What implementation is the other side? If the 
other

side is also Firefox, what does about:webrtc show there? What webrtc
service are you using? From an ICE perspective things look OK on your 
end;
if peer reflexive works, it makes sense to avoid using a relay after 
all.

Stuff can still fail after that though.

Hi,

I found a strange problem on my side. I have a PC under Airport WiFi AP
(but connected by wire), and try to use RTCPeerConnection to connect 
the

other device. However, the ice status is changed as "connected", but I
can't see any video on my FF. I also try to use about:webrtc to find 
the

any clue.. Here is the output from about:webrtc


Airport and hotel wifi/routers/firewalls are often horribly draconian, 
and in particular often will not allow peer-to-peer (peer reflexive) 
operation for various reasons (starting with protecting users from 
other users with viruses who are behind the same firewall, and less 
'nice' reasons as well).  Now, this may not be your issue since it 
seems to have selected peer-reflexive and presumably that requires 
packets to pass between them. However: The network situation may also 
be odd since I see both 192.168.x.x and 10.x.x.x addresses in use.  
Multiple interfaces? layered NATs?


My first suspects for multiple private IPs for local candidates are VMs 
of some kind.


But what makes me suspicious is that two 192.168.x.x addresses got 
selected and Aslan did not mention that the call is happening in a local 
network. Is this maybe a call via VPN into the office or something like 
that?


Best
  Nils

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

Re: Ice connection fails with STUN with cloud instance

[Nils Ohlmeier]

Hi Francois,

On 10/16/14 1:36 AM, regno...@temasys.com.sg wrote:

I'm working with a MCU and I encounter a problem only and only when the MCU is 
online (on the cloud - Amazon).

The ice connection fail. It happens most of the time (95%). But surprisingly 
sometime the connection successfully connects.

This problem doesn't happen when I test locally.

Hopefully you are aware that your AWS machines are running on private 
IPs (yes it has a public IP, but the network code needs to specify the 
public IP to listen on to be reachable on it - as our ICE doesn't do 
that it behaves as if it behind a NAT). I assume your machine you are 
running Firefox on is not on a public IP address either. So you are 
trying to connect two WebRTC clients behind NAT's. My guess is that your 
setup requires a TURN server and you currently don't provide one.


Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC - Delay increase in audio calls

[Nils Ohlmeier]

Hi,

On 10/13/14 11:26 AM, Henrique Rosa wrote:

Hello,

I've been working on WebRTC support for Mobicents Media Server (MMS).
I already succeeded at interop between MMS and Firefox/Chrome.

Unfortunately, while testing conference calls I noticed that there is a 
tendency for RTT times and Delay to increase as the call goes on (on both 
browsers).

On Chrome, the delay ranges from 3 to 10 seconds for a conference call between 
two participants with duration of 3-4 minutes.
On Firefox the results are much better: the delay ranges from 1 to 3 seconds in 
the same scenario.
Note that while testing with regular SIP clients (jitsi, linphone, xlite) there 
is no delay whatsoever, so the issue is related with WebRTC calls.

My question is: what can possibly cause such delay?

The one obvious difference between WebRTC and "regular SIP clients" is 
the additional media encryption. But should not take seconds, at least 
if you are using modern desktop PC.


The other question is how much delay FF and Chrome add between capturing 
audio and actually sending them out on the wire. And on the other end 
how delay there is between receiving audio packets and rendering to your 
audio device.


Best regards
  Nils Ohlmeier

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

Re: Warning: "Mandatory/optional in createOffer options is deprecated!..." in FF 33 Beta - what does it mean?

[Nils Ohlmeier]

On 10/6/14 12:15 PM, Adam Roach wrote:

On 10/6/14 12:39, Nils Ohlmeier wrote:


On 10/3/14 1:23 AM, asla...@amaryllo.eu wrote:
On Sunday, September 21, 2014 3:56:32 AM UTC+8, m.goff...@free.fr 
wrote:
I have the other problem. When I creating offer by using 
"{'mandatory': {'OfferToReceiveAudio': true, 'OfferToReceiveVideo': 
true}}", FF 33 will tell me "Mandatory/optional in createOffer 
options is deprecated! Use 
{"offerToReceiveAudio":true,"offerToReceiveVideo":true} instead 
(note the case difference)!". However, the offer is still created 
successfully and function onCreateOfferSuccess is called. But if I 
use "{'mandatory': {'offerToReceiveAudio': true, 
'offerToReceiveVideo': true}}" to create the offer again, FF 33 will 
call function onCreateSessionDescriptionError. The error is "Cannot 
create SDP without any streams.".
That sounds like a bug to me, which probably got introduce when the 
new constraints got implemented. If you haven't done it already I 
would appreciate if you could file a bug report on Bugzilla about that.


No, this isn't a bug. What happened is that the spec for 
PeerConnection no longer includes "mandatory" at al.


The string that Aslan used was "{'mandatory': {'offerToReceiveAudio': 
true, 'offerToReceiveVideo': true}}"


You'll see that it still contains the word "mandatory." He didn't fix 
the problem that the warning was telling him about 
("Mandatory/optional in createOffer options is deprecated").


What the error is trying to say is:
  Old syntax: {'mandatory': {'OfferToReceiveAudio': true, 
'OfferToReceiveVideo': true}

  New syntax: {'offerToReceiveAudio': true, 'offerToReceiveVideo': true}

So basically the old 'mandatory' ignores the new parameters 
'OfferToReceiveAudio' and 'OfferToReceiveVideo'. Therefore the 
'mandatory' part is empty. Which results in a PeerConnection with 
sendrecv, which then complains about the missing media input.


Nice mix-up of old and new config parameters.

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

Re: Warning: "Mandatory/optional in createOffer options is deprecated!..." in FF 33 Beta - what does it mean?

[Nils Ohlmeier]

On 10/3/14 1:23 AM, asla...@amaryllo.eu wrote:

On Sunday, September 21, 2014 3:56:32 AM UTC+8, m.goff...@free.fr wrote:

Thanks Jan-Ivar for your explanation.

The warning is not a big issue by itself, nut I thought I was missing something 
(I am rather new to webRTC...)

I have the other problem. When I creating offer by using "{'mandatory': {'OfferToReceiveAudio': true, 'OfferToReceiveVideo': 
true}}", FF 33 will tell me "Mandatory/optional in createOffer options is deprecated! Use 
{"offerToReceiveAudio":true,"offerToReceiveVideo":true} instead (note the case difference)!". However, the offer 
is still created successfully and function onCreateOfferSuccess is called. But if I use "{'mandatory': {'offerToReceiveAudio': true, 
'offerToReceiveVideo': true}}" to create the offer again, FF 33 will call function onCreateSessionDescriptionError. The error is 
"Cannot create SDP without any streams.".
That sounds like a bug to me, which probably got introduce when the new 
constraints got implemented. If you haven't done it already I would 
appreciate if you could file a bug report on Bugzilla about that.


Thx
  Nils Ohlmeier

Will this behavior be in FF 33 official release? Or this is a bug? In my case, 
I only want to receive the remote video stream, so I needn't get any local 
media stream. Or what shall I do if I only want to receive remote media streams?

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


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

Re: Release process and server monitoring for Open H264

[Nils Ohlmeier]

On 8/13/14 11:21 AM, Ethan Hugg wrote:

I think there are definitely some concerns here.

>> 1. How we are going to handle updates on the plugin?

I'm not currently planning to update the plugin again for FF34 but it 
could suddenly become necessary because of either a gmp-api change or 
new bug found.   The current process would be for me to create a bug 
assigned to the build team with the commit ID of github/cisco/openh264 
like this: https://bugzilla.mozilla.org/show_bug.cgi?id=1043416The 
build team would send me back the items to put on the CDN and update 
the information on the update server.   There should probably be a QA 
pass between the CDN update and the update server changes somehow.



I'm glad we talk about this now :-)
Is there then a way to push the new binary to the CDN, but in an 
in-active state (so not all browsers would automatically fetch it) so 
that QA's can manually point there browser (or other test framework) at it?
My hope is that a QA could maybe modify the media.gmp-manager.url user 
pref to point to such a new binary.
Also I'd like to point out that some of this code is missing automated 
testing.  It particular the code in openh264 that wraps it into a gmp 
plugin (gmp-openh264.cpp).  The basic encode/decode functionality is 
tested with the CI of openh264 and Firefox has testing of GMP with a 
fake plugin but this bit of code is in between.
Thanks for pointing that out. I think we are also completely missing any 
automated test around the download of the plugin. That's what I'm 
working on right now.


 >> Do we plan to deploy updates regularly, or only on a per need base?

I'm only planning to update the plugin on a per-need basis.  We don't 
have outstanding crash/leak bugs on it and I don't think we need more 
functionality so that mostly leaves reacting to changes in the API.



Sounds good.

Thanks
  Nils Ohlmeier

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

Re: Update: simplepush development and planning (for loop)

[Nils Ohlmeier]

Only one question:

On 8/13/14 3:43 PM, Ben Bangert wrote:

Adam indicated that it seems reasonable that 20% of Firefox users might click 
the Loop icon, which would be around 100 million connections. Confirmation or 
refinement of that number would be helpful. For this load we would deploy 
multiple loopPush clusters and provide a URL that the loop client would query 
before initially connecting to determine which clusters have capacity to handle 
more connections.

I'm assuming the guess of 20% is based on the assumption that  the Loop 
client will require FxAccount by the time of launch, right? Because if 
the Loop icons stays as prominent as it is in the URL bar and it does 
not require any auth before generating a click-to-call URL I would 
assume the percent number for users clicking the just icon to find out 
what it does should be way higher.


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

Release process and server monitoring for Open H264

[Nils Ohlmeier]

Hello,

after the OpenH264 plugin is landed and usable now I started to wonder

1. How we are going to handle updates on the plugin?
2. Do we need/want any monitoring of the download server and/or the
   download success/failure rate?

As development on OpenH264 seems to be pretty active I assume that we 
will deploy/push updates at some point to our download server.


 * Do we plan to deploy updates regularly, or only on a per need base?
 * How will we test such updates (as we don't have any automated tests
   (I don't consider the fake plugin to give us any decent test
   coverage here) I fear we are stuck with lots of manual testing here)?

Even without deploying any updates of the plugin I'm concerned how do we 
learn if something is broken for end users if anything is wrong on the 
download server end. For example the server becomes unreachable, or the 
XML can no longer be parsed, or...
My assumption here is no matter what goes wrong here the result will be 
that a new user would end up with no H264 support on his browser. I'll 
leave it to other people to judge how bad that would be.
I think it is pretty hard to predict how likely it is that we will run 
into any kind of errors which results in plugin downloads not working. I 
hope someone is monitoring the actual server.


 * But do we have for example telemetry data for success or failure
   rate of the plugin (or how many times a browser re-tried before it
   successfully downloaded the plugin)?
 * If we don't have any or not enough visibility into download success
   rates, is it worth investing into more monitoring or do we consider
   the risk so low or the result not important enough to invest into
   more monitoring?

Maybe all of this has been taken care of and I'm just not aware of it. 
So any feedback on this topic is welcome.


Best Regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Loop minimum viable calling solution

[Nils Ohlmeier]

Hi,

not sure if this is best place to start a discussion, but I wanted to 
throw out my view on a minimum viable calling solution for loop.


The link clicker in my view is not an acceptable solution for the end user.
It would be as if I give my parents a phone number where reachable for 
the next X hours, but if they want to call me tomorrow they first need 
to ask me via email (or some other communication tool) what my number 
today is. In my experience this is really hard to explain to 
non-technical people.
The other reason is that on mobile devices it is not easy to copy a URL 
from a calling app into some other communication tool to send it out to 
some.


On the other hand on desktop I don't see why we have to have an address 
book integration a.k.a. contacts. This is only valuable if my address 
book contains the Firefox Account email of my contact, or the contact 
has verified his phone number via the Loop MSISDN server. Both are 
pretty unlikely in my opinion.


Never the less I think a direct calling solution based on authenticated 
URLs is viable. If we integrate Firefox Accounts that would allow me to 
hand out either my email address or maybe permanent URL like 
loop.com/nils as the URL where I'm permanently reachable. Without an 
address book integrated into the Loop client this would require some 
form of input field where I can enter the email address or URL of the 
target user. But that should be easy to implement.
We could also store once dialed email addresses or URLs locally for 
convenience until we have a server based address book integration.


Best regards
  Nils Ohlmeier
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC, screen capture and Firefox OS

[Nils Ohlmeier]

Hi Paul,

try turning on media.getusermedia.screensharing.enabled in the user prefs.
The latest tests in bug 1039666 should help you figure out how to get it 
working.


Firefox OS does not support screen sharing right now.

Best
  Nils Ohlmeier

On 7/23/14 6:02 AM, Paul Rouget wrote:

I've seen plenty of bugs about screen capture and webrtc.
What is the status of that?

Is it possible to capture Firefox OS' screen and stream it
to desktop?

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


___
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

[Nils Ohlmeier]

On 5/14/14, 11:06 AM, ushunmu...@gmail.com wrote:

Martin - I think you are talking about bug #998546.  In my asymmetric call 
case, however, onaddstream never fires.
As described in comment #2 in bug #998546 onaddstream never fires if no 
audio or video tracks are specified.

My guess is that your problem is related.

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

Re: Ideas for about:webrtc

[Nils Ohlmeier]

On 4/15/14, 9:55 PM, Randell Jesup wrote:
I'm looking to compile ideas for improving about:webrtc.  Even stuff 
that's further out, though I'm most interested in what we can do for 
32, and build on after that.


Thus far:
* View Last Call (shows final stats/logs from last call to end)
* Add a Copy To Clipboard button ala about:support
* Add OS, version, and Mozilla version/buildID or UA string
* live updating of some values (in-call stats)
** graphing values from live updates
* Human-readable summary of connection status (and maybe color-coding)
** Connected via TURN, media flowing.  Connected peer-to-peer, media 
never flowed.  Connection lost.
* color-coding stats values (have ranges for colors) such as packet 
loss, etc

* expand/collapse ala about:memory
* more stats values, including non-standard ones
* Highlighted warning about missing TURN servers (if no connection got 
established)

* Advanced or debugging section
** View SDP
** ICE logs
** Ability to start/stop logging audio output (MOZ_DUMP_AUDIO) on the fly
** Ability to start/stop AEC inputs/outputs dump
** Ability to start/stop/save off the webrtc_trace logs
** (tricky perhaps) Start/stop various NSPR logs
*** some of these log changes might require taking affect in the next 
call

** datachannel stats
** Turn on/off AEC/AGC/NoiseReduction
*** already available in about:config
** change mode for AEC/AGC/NoiseReduction
*** already available in about:config

Oh yes:
* Ponies

* Rainbows

Best
  Nils

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