Re: WebRTC Service: On temporary call URLs

[Martin Thomson]

I think that you need to consider confidentiality here as well.  It might be 
desirable to have the addressing information concealed.  That implies a 
mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens

Now for a variation on a well-worn screed that I had to repeat many times while 
I was at Skype...

I think that the general guidance for designing APIs on HTTP is that URLs 
should not represent actions, they should represent things.  So /call/ might be 
OK in the noun sense, but if the intent is to load this with other actions, I 
think that I might have to question the wisdom of that.  Not knowing what these 
implied other actions are makes it hard to assess this properly though.

As it stands, I believe that we have two things here: a registry of contact 
URIs, and a registry of calls.  So the nouns might be /contact/{token} and 
/calls/{token}.

That leads to the next concern, which is that committing to a URI format is not 
wise in general because that can dictate server architecture.  If you do as you 
describe (s/http/https), then loop.services.mozilla.com is it.  You can't hand 
out tokens that reference a specific deployment or server, you can't move stuff 
without paying redirect or proxying costs.

Since you are minting tokens anyway, why not provide clients with all the URIs 
they will need, in full, when the token is minted.  Then you can hand clients 
off to https://idontcareabout.loop.services.mozilla.com.itspants.for.me/ and 
change URI layouts and all sorts of magical stuff.  The only fixed part is the 
starting point.

I'll also note that /call/1/... and /call/... are identical in very many 
respects.  The first is revised by increasing 1 to 2, the second by picking 
another name.

(I have a design for a RESTful registrar API if you are at all interested.  I 
built two of those in the past year, it's a fairly straightforward pattern.)

- Original Message -
From: Adam Roach a...@mozilla.com
To: dev-media@lists.mozilla.org
Sent: Wednesday, February 19, 2014 7:52:53 PM
Subject: WebRTC Service: On temporary call URLs

[For the tl;dr, skip down the the line starting Putting this all 
together.]

I realize that, while I've had a few discussions with people about the 
nature of the temporary calling URLs, I haven't really communicated some 
of the requirements we have around them, and how we can meet those 
requirements.

Users need the ability to revoke a URL that they have passed out -- if 
it, for example, falls into the hands of marketers or people from whom 
they do not wish to receive communications, users need a means to tell 
the server that the URL can no longer be used to reach them. This means 
the calling URLs must be unique each time they are generated; and, 
ideally, will identify the party to whom they were given. This also 
means that the URLs need to be tamper-proof, which implies some form of 
integrity protection.

Second, for this kind of system where users can and will create 
boundless state at a potentially rapid pace, we need to ensure that the 
server is not required to store all that state -- it just doesn't scale. 
This means the calling URLs need to encode all the information necessary 
to identify the called party and the calling party.

Now, revocation is inherently state that we need to store; but 
revocation events should be infrequent. Nonetheless, we don't want to 
store such state in perpetuity, which means all calling URLs need to be 
time bounded: once a URL expires, we can discard any associated 
revocation state. We can also optimize the size of the data we need to 
store for revocation: by including a short, unique serial number in each 
URL, a revocation record can consist simply of that serial number along 
with a date after which the URL is no longer valid (and, consequently, 
after which the revocation can be discarded). Both pieces of information 
are readily available from a URL each time it is used. If we use, say, 
64-bit serials and 32-bit expirations, this requires nominally 96 bits 
of state per revocation, which is pretty cheap.

Ideally, we also want the ability to identify multiple versions of URL 
encodings, should we decide to migrate to include an enhanced scheme in 
the future.

Putting this together, what we want is something that semantically 
evaluates to:

http://authority/action/url-format-version/{serial 
#,caller,callee,expiration,hmac}

Where hmac is an HMAC that includes the serial #, the caller, the 
callee, and the expiration. We may find that we want to add more fields 
to the part I have inside brackets here; using an explicit URL format 
versioning allows us to do this very easily.



For example (and this is meant to be illustrative, not normative), a URL 
that is minted to call from a...@mozilla.com to a...@nostrum.com, 
with an expiration of March 1st, 2014 at 21:19:13 CST might crafted 
first by concatenating these 

Re: Naming the project

[Martin Thomson]

I think that this fails one of the basic criterion that Andreas laid out.  
Namely, that it can very easily be mistaken for a product name.  I can imagine 
taking this to a public announcement.

On 2014-02-20, at 00:57, Romain Testard rtest...@mozilla.com wrote:

 Hi all,
 
 Thanks for your input regarding re-naming the project.
 This came to a draw between Loop and Archway and we decided that Loop is a 
 good name for the WebRTC application project (the product name will be 
 different).
 Loop is concise, fits all of Andreas requirements and can be turned into a 
 verb just like you do with Skype (Loop me in).
 
 So please use Loop to name the project moving forward - a Wiki using the 
 Loop name will be created and I'll be in touch with some of you to get that 
 going.
 
 If you see any issues with it please let me know!
 
 Romain
 ___
 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 Service: On temporary call URLs

[Martin Thomson]

On 2014-02-21, at 09:58, Romain Testard rtest...@mozilla.com wrote:

 Guys, I want to clearly understand, will this prevent URL customisation 
 (mz.la/romain) as well as easy to remember generated URLs 
 (mz.la/two_driving_dolphins) ?
 I'm not sure we want to do these things but I want to understand the 
 implications of that decision.

I don’t think that there would be a problem with using a URL shortener.  If the 
question is whether you might be able to generate call URLs with vanity paths, 
then I think that the answer would be no: that’s what a URL shortener is for :)
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Camera / Mic popup disappears when browser looses focus

[Martin Thomson]

On 2014-04-17, at 12:36, Randell Jesup rje...@mozilla.com wrote:
 No event is fired when this happens which makes it very tricky to react to
 in the UI.
 
 Yes; this is a common issue.  Right now there's no easy way to deal with it, 
 as you've seen.

Yes, common.  We occasionally angry comments on 
https://bugzilla.mozilla.org/show_bug.cgi?id=947266

So far, we’ve resisted adding any sort of feedback when the door hanger is 
hidden.  Since this is a non-terminal state (the door hanger can be opened and 
consent actually granted or denied), there isn’t a good way to provide this 
feedback to applications.

Yes, this makes your application a little less aware.  But we don’t want to 
remove user control.  If it were possible for an application or site to open 
the door hanger at will, then users could be badgered into consent.  We don’t 
want that.  We also don’t want to reveal what is happening with browser chrome. 
 That’s our user’s business.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: dev-media Digest, Vol 26, Issue 12

[Martin Thomson]

On 2014-04-18, at 02:59, Jamie McDonnell jamie.mcdonn...@gmail.com wrote:

 This is the current error but it seems to have gone quiet - any progress on
 this:
 https://bugzilla.mozilla.org/show_bug.cgi?id=895971#c24

As noted in the bug, that issue is invalid.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: dev-media Digest, Vol 26, Issue 12

[Martin Thomson]

On 2014-04-19, at 00:38, Jamie McDonnell jamie.mcdonn...@gmail.com wrote:

 what is the suggested approach for this scenario when a user alt-tabs away 
 from the browser, or it looses focus while a gUM request is in progress?

You can show an indicator in content that you are awaiting user input [1].  How 
is that not sufficient?

Note that even if we were to provide an event in this scenario, we could not 
provide the application with any way to retrigger the door hanger for the 
aforementioned reasons.  So I’m not sure that there is anything actionable from 
the application perspective.

—Martin

[1] I note that you could place this indicator in the area that the door hanger 
occludes if you only want it visible to users who had it lose focus.  Though I 
note that requires UA detection, which is definitely undesirable.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Mapping AudioStreamTrack to AudioTrack

[Martin Thomson]

On 2014-04-23, at 04:39, Marco Chen mc...@mozilla.com wrote:

 2. Then there are multiple MediaStreamTrack to represent multiple audio/video 
 tracks in TV stream. 

I don’t know if this is a problem here, or whether it’s just a 
misunderstanding, but the structure of MediaStream is actually three-deep:

MediaStream is a synchronisation container
MediaStreamTrack describes a single type of related content (e.g., audio, or 
video)
channels are not visible in the DOM, but they correspond to a single piece of a 
track (e.g., the left speaker channel in multi-channel audio)

When you say that there are multiple MediaStreamTrack instances, do you mean to 
say that there is media from multiple sources (e.g., separate cameras, 
different translations), or are you talking about media with multiple parts 
(e.g., 5.1 channel audio)?

Why is it necessary for MediaStreamTrack to carry tags that identify things as 
(for example) English or Mandarin?  Is it not possible for this labelling to 
occur in the application?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Mapping AudioStreamTrack to AudioTrack

[Martin Thomson]

On 23 April 2014 21:13, Robert O'Callahan rob...@ocallahan.org wrote:
 I think it would be a good idea to align AudioTrack/VideoTrack and
 MediaStreamTrack by changing their specs.

 I think the best thing to do would be to change MediaStreamTrack to fit
 AudioTrack/VideoTrack. E.g. we could change MediatStreamTrack.kind to type
 (and add it to AudioTrack/VideoTrack), and add kind and language to
 MediaStreamTrack.

 Martin, what do you think?

That's sensible, though I wasn't previous aware of the distinction.

MediaStreamTrack : AudioTrack, EventTarget seems like a natural fit.
That doesn't leave much that MediaStreamTrack adds, but that also
sounds just about right.

Language will pretty much invariably be  for the cases I know,
that's OK, and everything else just works.
___
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

[Martin Thomson]

On 2014-05-14, at 08:39, Brent Gracey brentgra...@gmail.com wrote:

 The setRemoteDescription callback is firing and pc.getRemoteStreams()[0] is 
 returning a stream, so I think I'll be able to use the work around

Note that there is an open bug regarding the onaddstream event firing too late 
in Firefox.  You should eventually get the event, but not before the 
setRemoteDescription callback.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Mapping AudioStreamTrack to AudioTrack

[Martin Thomson]

On 2014-05-27, at 09:16, congnguye...@gmail.com wrote:

 Hi, could you please show me an example code of a MediaStream which contains 
 multiples MediaStreamTrack of multiple cameras. I have been trying to switch 
 the camera using MediaStream.getVideoTracks(), but there was only one video 
 track in the stream even though I have two cameras connected.

Firefox only supports 0..1 audio and 0..1 video tracks in a MediaStream.  I 
don’t know what our plans are regarding a fix.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Using a video as a *source*?

[Martin Thomson]

On 14/07/14 11:22, Adam Roach wrote:

Heh. I guess I stand corrected on that point.


:)  We've had this for ages.  There might be some gotchas, but I've used 
it successfully for some times (but it's failed me for some corner cases).

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

Re: getUserMedia constraints

[Martin Thomson]

Firefox nightly has patches for these constraints in the form described by the 
editor’s draft.  Though this is an area of the specification that is still in 
flux.

http://dev.w3.org/2011/webrtc/editor/getusermedia.html

On 2014-07-21, at 08:54, matteo.brun...@gmail.com wrote:

 Hi,
 
 i've already realized a simple demo for the web rtc features available in 
 firefox but i've one question about the getUserMedia constraints that seems 
 to be ignored by firefox.
 
 If i ask the camera availability to the user with:
 getUserMedia({
   audio: false,
   video: true
 }, userAcceptMedia, userDidNotAcceptMedia);
 
 i got the camera control and it record video with size 640x480 from webcam.
 
 If i want to customize the recording dimension on other browser, like chrome, 
 i can add media constraints like this:
 
 getUserMedia({
   audio: true,
   video: {
   mandatory: {
 minWidth: 352,
 minHeight: 198,
 minFrameRate: 15,
 maxWidth: 352,
 maxHeight: 198,
 maxFrameRate: 15
   }
   }
 }, userAcceptMedia, userDidNotAcceptMedia);
 
 and then chrome record the video with size 352x198, but firefox record the 
 video always with size 640x480.
 
 There is a way to do that also on firefox? media constraints are not 
 implemented yet on firefox?
 
 Thanks in advice for the answers!
 Matteo
 ___
 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: Working solution for live-streaming to Firefox (OS)?

[Martin Thomson]

I wouldn't have said that it's strictly bad.  Did you plan to have a server 
involved at all?

- Original Message -
From: Felix E. Klee felix.k...@inka.de
To: dev-media@lists.mozilla.org
Sent: Wednesday, October 22, 2014 4:43:17 PM
Subject: Re: Working solution for live-streaming to Firefox (OS)?

On Wed, Oct 22, 2014 at 5:51 PM, Felix E. Klee felix.k...@inka.de wrote:
 What about WebRTC?

Just read that broadcasting WebRTC is possible but terribly
inefficient and with tight limitations on the number of connections:

https://github.com/muaz-khan/WebRTC-Experiment/tree/master/webrtc-broadcasting

This experiment is for broadcasting from the Chrome browser, but maybe
it's possible to broadcast from Node.js - no idea. Anyhow, WebRTC
looks like a bad idea.
___
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: Audio output device selector

[Martin Thomson]

 On 2014-12-03, at 06:24, Balázs Sándor balazs.san...@virtual-call-center.eu 
 wrote:
 
 Can I change the audio output device?

Currently, no.  There is a plan to provide this capability.  It was discussed 
at the last W3C meeting.  I don’t think that it has been prioritised (yet).
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: streaming rtp packets to http chuncks?

[Martin Thomson]

The MediaRecorder API enables something like this, though I'm not sure how
playable an in progress recording is.

I'm fairly certain that this will not achieve any performance gains though,
if that is your goal. It might be ok if you are able to tolerate delays,
possibly accumulating delays.
On Mar 28, 2015 5:26 AM, vyp...@gmail.com wrote:

 Hi all!

 Taking into account the maximum number of connected streams(RTP) to a
 browser per domain and as a consequence the scalability problems and the
 need of using media servers i'm wondering if it is possible to get streams
 from a peer and transform them in http chuncks?

 Any ideas? Projects? I need some guidelines and opinions about the
 feasibility of this approach.

 Thanks.

 ___
 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: Implemented simple Identity Provider, kills RTCPeerConnection

[Martin Thomson]

On Fri, Jun 19, 2015 at 2:30 AM,  haefner.christ...@gmail.com wrote:
 I'm trying to implement an identity provider and hitting a roadblock
 My very minimalistic implementation (https://pastebin.mozilla.org/8837137) 
 makes the RTCPeerConnection unuseable, as the createOffer doesn't work 
 anymore (onError is called with an empty error object).

 Is there anybody who could hint me in the right direction.
 Any help is highly appreciated!


Good to see someone giving this a go.

The API has changed significantly since you last saw it.  You'll
likely be pleased to learn that the API is much more direct.
http://w3c.github.io/webrtc-pc/#identity

You can see a sample implementation here, though that is intentionally
complex because it supports a number of tests:
https://dxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/identity/idp.js

The onerror thing is a little unfortunate, I will look into that.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC DTLS cipher suite selection logic

[Martin Thomson]

On Wed, Sep 30, 2015 at 1:15 PM,   wrote:
> Where can i find information on how Firefox is selecting the cipher suite to 
> be used from the list of cipher suites it receives in DTLS ClientHello ?


The only place that lives now is in the NSS code.  You can see the
preference order here:

https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#89

We disable a good number of those suites though:

https://dxr.mozilla.org/mozilla-central/source/media/mtransport/transportlayerdtls.cpp?from=transportlayerdtls.cpp=0#674
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: removeTrack throwing error

[Martin Thomson]

On Tue, Dec 15, 2015 at 9:14 PM, Balwant Bisht  wrote:
> Any idea how to track this issue?


bugzilla.

Please open a bug here:
https://bugzilla.mozilla.org/enter_bug.cgi?component=Audio%2FVideo%3A%20MediaStreamGraph=Core
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Incorrect SDP answer from Firefox

[Martin Thomson]

On Wed, Jan 6, 2016 at 9:17 PM, OrdinaryWorld
 wrote:
> Is the listing of the video stream as recvonly correct? If so, how do I get 
> FF to not receive or send video in the answer?

a=recvonly is correct.  Offers and answers are expressed from the
perspective of the entity generating the SDP, so a=recvonly indicates
that the endpoint doesn't have anything to send.  It doesn't in your
case.

As Byron says, unless you actually have a video track, Firefox won't
(and can't, by specification) generate an a=sendrecv media section.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: bogus candidates

[Martin Thomson]

On Fri, Mar 18, 2016 at 4:24 AM, Byron Campen  wrote:
>> (ice/WARNING) Error parsing attribute: candidate:1316968211 1 UDP
>> 2130706430 91.224.14.66 8001 typ srflx generation 0
>>
>>
>> What's wrong with this ICE candidate ? Firefox wants raddr & rport ?
>
> Yes, raddr and rport are required on srflx, prflx, and relay candidates
> according to RFC 5245.


Also note that generation isn't needed.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox cannot act as DHE server

[Martin Thomson]

On Fri, Mar 11, 2016 at 7:28 PM,   wrote:
> Martin, just to double-check: by 'client' you mean WebRTC client, and not the 
> remote node which is sending the DTLS client hello towards FF, right?

Since we were talking DTLS, I mean the DTLS client.  That is usually
the WebRTC peer that generates the answer, if that helps at all (or
the one that explicitly sets a=setup:active in its offer).
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox cannot act as DHE server

[Martin Thomson]

On Fri, Mar 11, 2016 at 10:18 AM, Nils Ohlmeier  wrote:
> Have you read this hack post already?
> https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrecy-pfs-starting-in-firefox-38/

That posting isn't quite relevant, this is:

> TLS_DHE_***RSA***_...

Firefox won't act as server for RSA-based cipher suites without the
certificate management API.

That's here:

https://developer.mozilla.org/fi/docs/Web/API/RTCCertificate

It's perfectly happy to be a client, because the cipher suite doesn't
constrain the certificate that a client can use.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox 48 WebRTC DTLS change question

[Martin Thomson]

This is likely a retransmission.  NSS has fairly aggressive timers for
retransmission of DTLS messages.  If your ServerHello doesn't arrive
quickly, then you will see a second ClientHello after 50ms and a third
after another 100ms.  As long as the handshake completes successfully,
I wouldn't worry about this.

On Tue, Jul 26, 2016 at 11:38 PM,   wrote:
> Firefox 48 always sends a double DTLS hello message when acting as the 
> client, where FF47 and other browsers only send one.  This happens using our 
> product and also in AppRTC.
>
> The first hello has seq=0, message_seq=0,
> and the second has seq=1, message_seq=0.
>
> Does anyone know why this change happened, and is it a fix, or a bug?
>
> E.g.:
> Protocol Length Info
> DTLSv1.2 211Client Hello
> DTLSv1.2 211Client Hello
> DTLSv1.2 129Server Hello
> DTLSv1.2 567Certificate
> DTLSv1.2 268Server Key Exchange
> DTLSv1.2 67 Server Hello Done
> DTLSv1.2 129Server Hello
> DTLSv1.2 567Certificate
> DTLSv1.2 268Server Key Exchange
> DTLSv1.2 67 Server Hello Done
> DTLSv1.2 208Client Key Exchange, Change Cipher Spec, Encrypted Handshake 
> Message
> DTLSv1.2 208Client Key Exchange, Change Cipher Spec, Encrypted Handshake 
> Message
> DTLSv1.2 60 Change Cipher Spec
> DTLSv1.2 103Encrypted Handshake Message
> DTLSv1.2 60 Change Cipher Spec
> DTLSv1.2 103Encrypted Handshake Message
> DTLSv1.2 81 Encrypted Alert
>
>
> Thanks,
> Jennifer
> ___
> 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: Firefox 48 WebRTC DTLS change question

[Martin Thomson]

On Fri, Jul 29, 2016 at 5:47 AM,   wrote:
> It was causing problems in our implementation when we received the second 
> client key exchange sequence after the handshake was already completed.  I 
> fixed it by filtering out the retransmitted messages before they get 
> interpreted by our protocol.

Implementations need to handle retransmission of a client's second
flight of messages.  If the server's final flight of messages is lost,
retransmission of the client's messages are what trigger
retransmission of the server's messages.
___
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

[Martin Thomson]

On Fri, Feb 3, 2017 at 2:51 AM,  <ushunmu...@gmail.com> wrote:
> @Martin Thomson  Thank you for the info.  Do you know which version of 
> Firefox this fix will land on?

Firefox 53.  https://bugzilla.mozilla.org/show_bug.cgi?id=1317947
___
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

[Martin Thomson]

On Thu, Feb 2, 2017 at 11:37 AM,   wrote:
> BTW, it seems to me that Firefox should be using a more widely used ECDH 
> named curve, such as secp256r1, when the Client Hello does not list the 
> supported named curves. This would make Firefox more compatible with older 
> implementations. I suppose security and speed may be factor here, but isn't 
> it a bit too soon to make this change?


This is in fact how Firefox will operate in future.  The error, that
exists in Firefox 51 (and maybe 52) is that we assume support for all
of the groups that are enabled on the server.  That will not be the
case soon, we will only assume support of P-256.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1330612
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

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

[Martin Thomson]

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.

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

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

[Martin Thomson]

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
>
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: screen sharing dialog problem

[Martin Thomson]

That checkbox is not useless, to a user who doesn't want to be
assaulted by dialog boxes from malicious or annoying sites (assuming
they still have cause to visit those sites).  I regularly have to fend
off advances that ask for notifications or geolocation permission on
sites that I have no interest in sharing that information with.

Sadly, we can't give away the ability to write browser UX, which
includes removing the annoyance controls we offer people who use
Firefox.  So your first three requests are ones we can't grant.

The addition of screen sharing to the permissions API is intended to
address your last point.  See
https://github.com/w3c/mediacapture-screen-share/issues/28  This is
something of a neglected piece of code, but if you care about this,
contributions are welcome.

On Wed, Apr 11, 2018 at 12:12 AM, Alexander Abagian  wrote:
> Hi,
>
> I'm faced with a UI problem concerning screen sharing dialog in FF 59. This 
> dialog offers two options : "Allow" and "Don't Allow" and a checkbox Remember 
> this decision.
>
> First of all, the checkbox is useless, if checked, "Allow" is disabled and 
> "Firefox can not allow permanent access to you screen" text appears. The only 
> alive button rest is "Don't allow".
>
> If an user select "Don't allow", then the dialog does no more appear at all.
> The user should find some icon left to the URL field and unblock sharing 
> first.
>
> Worse, this dialog is called in my app from another dialog which selects the 
> object type to be shared - screen or window.
>
>
> What I wish to have
> - best of all an ability to create my own dialog with needed options and 
> buttons (Cancel instead of "Don't Allow")
> - or ability to disable "Don't Allow" button
> - or ability to programmatically cancel screen sharing blocking
> - or at least let the script know if it's blocked or not
>
> Would you advise something ?
>
>
> https://yadi.sk/i/wZ03i-1Z3UHXBC
>
> https://yadi.sk/i/k8VllWVi3UHXDL
> ___
> 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: how to disable SRTP

[Martin Thomson]

SSLKEYLOGFILE integration with SRTP might be a better long term solution
here.

On Sat, 2 Mar. 2019, 07:23 Nils Ohlmeier,  wrote:

> 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
>
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Lossless video codec for web use?

[Martin Thomson]

Lossless video coding isn't really a thing on the internet.  There are
lossless modes in some encoders (x264 has one that I'm aware of), but they
tend to inflate inputs rather than compress them.  There are systems used
in video production that maintain all the source bits, but they use insane
amounts of bandwidth.

On Fri, Jun 14, 2019 at 6:37 AM Eric Shepherd (Sheppy) <
esheph...@mozilla.com> wrote:

> I’m working on my video codec documentation and have come across the point
> where I need to offer suggestions to developers who need to work with
> lossless video in a web app, for things like archival and video production
> work?
>
> As far as I can see, there aren’t at this time any dedicated lossless video
> codecs available in web browsers. Is there a lossless profile of one of the
> existing major codecs (AAC, AV1, VP8, or VP9 being the prime candidates, I
> suspect)?
>
> Some of them include a lossless functionality in the spec but the question
> is whether or not that capability is implemented by browsers and exposed in
> turn to the web app developer.
>
> Any input appreciated, thanks!
>
>
> Eric Shepherd
> Senior Technical Writer
> MDN Web Docs 
> Blog: https://www.bitstampede.com/
> ___
> 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