Re: screen sharing and webcam video simultaneously
On 2/16/18 2:04 PM, Alexander Abagian wrote:
I want to make Firefox stream both screen sharing and common webcam video
simultaneously. Is it possible at all ? Chrome lets do it with an external
screen sharing plugin, but here both of the should be produced by getUserMedia
and I haven't find a way how to make it. mediaDevices.enumerateDevices() does
never enumerate screen sharing. Constraints could contain a single video member
for both cam video or the sharing, but I need them both in the moment.
You should be able to grab both video streams and add them both to the
peer connection. Something like:
(async () => {
let pc = new RTCPeerConnection();
let camera = await navigator.mediaDevices.getUserMedia({video: true});
let screen = await navigator.mediaDevices.getUserMedia({video:
{mediaSource: "screen"}});
pc.addTrack(camera.getTracks()[0]);
pc.addTrack(screen.getTracks()[0]);
//...
})();
/a
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: Webextensions WebRTC API
On 9/8/16 1:18 PM, Andrew Swan wrote: First, I read through bug 1189060 in which the webrtc extension hooks were created. I'm concerned that I can't actually hook into the PeerConnection establishment process in a safe way. If extension A overrides webrtcUI.receiveMessage in the suggested manner, then extension B does the same, everything is fine. But then if extension A is unloaded, there's no way for it to unchain its handler. It can detect this at unload time but it can't actually do anything. Would a patch to address this situation be accepted? Who would be the right person to review such a patch? (Incidentally, I searched through the addons from addons.mozilla.org <http://addons.mozilla.org> that are indexed on DXR and there are none in the index that are using this hook, but we don't yet have everything from AMO indexed in DXR. That's all to say, I don't think there's a compatibility issue with changing the interface for this hook.) As you point out, this hook is currently used only very lightly today -- mostly likely because the existing documentation consists entirely of the hacks post you mentioned. I think that breaking changes should probably be okay. The necessary reviewers for your patch would depend greatly on which parts of the system you touch. The patches in 1186060 hit many modules, and ultimately had reviews from florian, fabrice, mfinkle, mt, peterv, and khuey. For changes in the webrtc module, I'd ask jib for reviews (rather than mt). For changes in DOM, probably bz (rather than khuey) Any other modules, I'd tag one of the 1186060 reviewers, since they'll have context. Second, looking past PeerConnection, what other things might we want to expose to extension authors? In the description for bug 1281833, Adam suggests "The ability to add, remove, or change IP addresses exposed by PeerConnections". This sound like a useful thing but I'm unfamiliar with the webrtc implementation, is this even feasible? What other things can/should we expose? What I'd expect here is the means to register a callback that is hit whenever a new ICE candidate is generated. The callback receives the candidate, and returns a Promise. Once it reaches a verdict on whether the candidate is allowed to be presented to the content, it either resolves or rejects the promise. (Or, if people don't like the aesthetics of a promise reject for normal operation, you can return a Promise). I'm actually not sure what I had in mind when I said "add" and "change", since this... won't be useful. Conveying addresses that the ICE stack isn't listening on would only make connection setup take longer and/or fail. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: [webrtc] Is DTMF support in the FireFox roadmap?
On 5/10/16 07:42, Maire Reavy wrote: On Tue, May 10, 2016 at 4:43 AM, Luis Silva <luisfilsi...@gmail.com> wrote: Hi guys, Any plans to support DTMFs in the next releases? Yes. We were originally targeting Firefox 49 (which is currently in development), but some important issues came up that we had to deal with. So it's more likely to ship in Fx50 --which goes to DevEdition on August 1st and to Beta on Sept 12th (and releases in November). Luis -- see also https://hacks.mozilla.org/2015/11/webrtc-sending-dtmf-in-firefox/ for a stopgap measure that may work for you. -- Adam Roach Principal Platform Engineer Office of the CTO ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: H.264 codec and/or SDP issues with RTCPeerConnection
accepted by RTCSessionDescription(), there is no remote video playing in Firefox. We could not find any error hint. We have prepared a test case: 1. open https://janus.bfs.de/ 2. select "Cisco MCU" 3. select "Connect" In contrast to that a RTCPeerConnection between Firefox and an OpenMCU-ru installation works flawlessly (same gateway, same JavaScript code): 1. open https://janus.bfs.de/ 2. select "Open MCU" 3. select "Connect" We have worked hard on this problem for several days now, but we could not figure out what is going wrong. We would really appreciate your advice, how to track down and fix this problem. Many thanks in advance and best regards, Christian ___ 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 -- Adam Roach Principal Platform Engineer Office of the CTO ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Air Mozilla Studio
WebRTC folks: I had a brief chat with Richard Milewski last week about a project he's working on, and wanted to drop a note to provide some context, as I suspect he'll be coming to #media (and/or using this mailing list) to ask for assistance as necessary. The project is tentatively titled "Air Mozilla Studio," although Richard expressed some desire to find a more general name for the effort. The general idea here is to use WebRTC to connect devices -- typically in the same room, although there's no reason that needs to be the case -- to a browser that serves as a central video production console. This console selects from one of several such devices (including devices local to the laptop), and can composite them with local graphics (foregrounds and backgrounds) into a single video stream. This video stream is then uploaded to a remote server using something like RTMP (or whatever YouTube uses nowadays) and/or an HSTS-like series of PUTs or PATCHes. This could be done either as the stream is recorded (e.g., near-real-time), or saved to local storage and uploaded at a later date. That's the basic functionality. Of course, doing things like screen sharing, chroma keying, and more advanced production would be nice future enhancements, but they're not the current focus. The rationale is to allow amateur users to be able to produce live and recorded streams with reasonable production values using nothing more than the equipment they would typically have available -- say, a computer and a couple of cell phones (used as remote camera/mic units). There's a bit more information as well as a mock-up of the basic interface here: https://people.mozilla.org/~rmilewski/AirMoStudio/ -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: How to force Hello Firefox to chose H.264 instead of VP8?
I think there's some confusion here. Ethan and Daasoundz DJ are talking about Hello. Byron and Randell are talking about WebRTC more generally. Daasoundz: The confusion probably arises from the fact that you say you're testing your webapp and that you're using Firefox Hello to do so. I have no idea how you plan to make this work, but the current design of Hello doesn't really contemplate interacting with non-Hello endpoints, and I can think of a large handful of problems you're going to run into in trying to do so. (To be clear, there is still a desire -- at least, among some people -- to eventually federate Hello with other clients, but that's way beyond our planning horizon for now.) I think you need to give a more detailed explanation of what you're trying to accomplish before anyone on this list can provide you with useful answers. /a On 6/29/15 09:37, Randell Jesup wrote: On 6/29/2015 2:38 AM, Daasoundz DJ wrote: Le vendredi 26 juin 2015 17:21:11 UTC+2, Byron Campen a écrit : You can also rewrite the local SDP to alter the priority. It's an idiot question but ... how can I rewrite the local SDP ? and/or where do I find it ? After you get the offer (from createOffer) or receive it (from the other end), modify the m=audio line in offer.sdp to put the payload number in the a=rtpmap line for G722 before all other audio codecs. i.e. ... m=audio number transport list of payload values ... a=rtpmap:payload G722/8000/1 (note: the /1 is optional) other a=rtpmap's You want payload to be the first in the list of payload values in the m=audio line. It's all just (careful) string manipulation. Don't assume any particular number will be used for payload! -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: device selection and getUserMedia in privileged code
Yes, this work is underway. See bug 1046245. /a On Mar 20, 2015, at 07:44, jolic...@gmail.com jolic...@gmail.com wrote: Hello, It seems impossible for privileged code (chrome://) to select a device for getUserMedia ( https://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#1715 ). I can use getUserMedia, but only the default device is used ( https://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#1193 ) Is there any workaround, or is it planned to add the functionality, it can be useful for extensions and xulrunner app. And I don't really understand the limitation. Thank you. Nicolas ___ 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: [webdev] Blog Post: Privacy and Google Analytics
I have some sympathy on the IE10 issue, and think a broader conversation is warranted there. With regard to DNT and GA as they apply to Hello, I'm not sure the situation is directly comparable to www.m.o: we're talking about a real-time communications service, not just a web page. People will rightfully be more concerned about privacy with Hello than they do going to our website. In earlier conversations with the legal department, the formal advice provided for Hello in particular was: Currently the policy regarding DNT and GA is inconsistent across the Mozilla and has been handled differently by different business owners. Marketplace for example turns off GA when DNT is on. That means the Hello team should set the approach for the moment. As I've mentioned in various conversations lately, Hello data is going to become some of the most sensitive stuff that Mozilla touches, so I'd suggest that we should have a bias in favor of privacy and user preference. In this case, that would mean respecting DNT. I've copied Marshall Erwin in case he wants to weigh in. /a On 2/26/15 13:45, Christopher More wrote: I commented in that bug that IE10 should be ignored as it does not signal user intent: http://en.wikipedia.org/wiki/Do_Not_Track#Internet_Explorer_10_default_setting_controversy You probably also saw my note on dev-webdev about DNT and GA and why we haven't disabled it on www.mozilla.org. If you haven't, I will copy/paste it below: Google Analytics isn't respecting DNT for a variety of reasons, but it doesn't technically mean that it can't. It would simply be a conditional statement around the tag loading. We have this conversation about every 6 months since 2012. :-) * GA does not collect PII. It's all aggregate trends as hit-level data isn't very useful. * We don't directly link the GA sessions/cookies to other 3rd party services for additional tracking * All cookies are 1st party Mozilla domain cookies. * We don't do cross-domain GA tracking as each sub-domain has its own unique tag and has a sub-domain filter attached to the GA profile. * We use GA to understand the UX and find out what is working. * We don't do GA re-targeting like other companies do as common practice. * We have opt-ed out (at the account level) of Google or 3rd parties from using the aggregate data to understand general trends. * We have enabled IP anonymization at the tag level for a few websites. Others Mozilla websites could do the same. * We provide a user opt-out of GA and Optimizely for sites that use them in our websites privacy policy. Idealistically, we could say that Apache, caching proxies, or our 3rd party CDN should not set server/router/network logs when DNT is enabled as that could be considered by some as tracking. I have also some some research on DNT on www.mozilla.org and while the percentage is small, there are some browsers that are enabled by default from the factory, which would make them pretty much disappear from metrics that are being used to understand the health of the Firefox product. Not having a clear picture on metrics could negatively impact the health of Firefox and ultimately lead to reduced impact on our mission. Oh wait, now I am being idealistic. :-) More light reading on the topic: https://bugzilla.mozilla.org/show_bug.cgi?id=858839 https://bugzilla.mozilla.org/show_bug.cgi?id=697436 -cmore On Thu, Feb 26, 2015 at 8:57 AM, Gavin Sharp ga...@gavinsharp.com wrote: +cmore, gareth I think most of these suggestions are already implemented (see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1129507). Gavin On Thu, Feb 26, 2015 at 12:48 AM, Alexis Métaireau ale...@mozilla.com wrote: Hi, Here is a set of good practices in the usage of Google Analytics. I believe we should implement these for the loop-client webapp, which is relying on GA currently. — Alex Forwarded Message Subject:[webdev] Blog Post: Privacy and Google Analytics Date: Mon, 23 Feb 2015 21:53:06 -0800 From: Chris Van Wiemeersch cwiemeer...@mozilla.com To: dev-webdev dev-web...@lists.mozilla.org I stumbled upon this blog post by fellow Mozillian, Guillaume Marty (gmarty): http://gu.illau.me/posts/privacy-and-google-analytics/ A few months ago on the Marketplace team we discussed whether Google Analytics should be disabled when Do Not Track is enabled. The consensus was no - but with an asterisk. This blog post is a good read for those who want to use Google Analytics without sacrificing user privacy (i.e., you!). Best, cvan ___ dev-webdev mailing list dev-web...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-webdev ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863
IETF Internet Video Codec (NETVC) BoF approved
We just got official word that the NETVC BoF (Birds-of-a-Feather) session has been approved for the upcoming March IETF meeting in Dallas. This is an important step in developing an internet-focused realtime video codec with favorable (and ideally royalty-free) licensing terms. I'll note that this isn't the formation of a working group to actually perform the work of developing a codec and publishing the specifications. In the IETF process, holding a face-to-face BoF session is designed to let the IETF community comment on the proposed charter for a working group before it is formed, and to determine whether forming a new working group is warranted. That said, I am very optimistic about the probable outcome of the BoF resulting in a new video codec working group. I'd like to extend a special thanks to the entire Daala team; their work has been critical in laying the foundation for the standards work that will follow, and this BoF would never have happened without them. I'd like to thank Tim Terriberry and Jack Moffitt in particular for doing all of the heavy lifting of driving the IETF process. I will be co-chairing the BoF. Feel free to reach out to me with any process questions you may have. A description of the BoF is here: http://trac.tools.ietf.org/bof/trac/wiki#NETVC The proposed working group charter that will be discussed is here: https://daala.etherpad.mozilla.org/video-codec-charter -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC: missing media type in SDP -- FF 33 beta
On 9/11/14 12:09, Rajarshi Chaudhuri wrote: Thx Adam. Checked the bug you mentioned. It is related - but anyway, specific to the issue I mentioned - even with the new format, the OfferToReceiveVideo value is not respected by Firefox v33 beta - that would be resolved in the release version? In the new format, OfferToReceiveVideo isn't valid. You need to use offerToReceiveVideo. If you're missing the difference, look very carefully at the first letter of those two different strings. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC: missing media type in SDP -- FF 33 beta
See https://bugzilla.mozilla.org/show_bug.cgi?id=1063808 /a On Sep 10, 2014, at 19:00, Rajarshi Chaudhuri ccrajar...@gmail.com wrote: Hi - For the current FF 33 beta, I see one issue with WebRTC. The problem is that when the user has only one media type (say audio or video, but not both), and creates an offer with both offerToReceiveAudio and offerToReceiveVideo set to true, previously the missing media type would still be in the offer SDP as recvonly. In current case - the missing media type is totally missing from the offer SDP. I It could be any recent change (as this was not there in earlier versions)? Thx RCC ___ 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: Using a video as a *source*?
On 7/14/14 13:20, Adam Roach wrote: On 7/14/14 13:15, Benjamin Smedberg wrote: Can I use a video element as a source for webrtc/peerconnection? For GMP testing, I was hoping to be able to feed a known video through webrtc, and not have to worry about actual camera stuff. Not yet... Heh. I guess I stand corrected on that point. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Loop Server MVP: Protocol and Architectural Enhancements
On 6/19/14 09:25, Mark Banner wrote:
A few follow-up comments having been looking through some of the bugs:
Getting Call Information
The mix of GET /call/{token} and GET /calls?version= is confusing
- to know which calls we have incoming, we have to get /calls, but the
new GET /call/{token} is going to give us the part of the
information we need to display before the call is accepted.
I'll see if I can clarify the language here, but these serve two very
different purposes, and don't ever make sense for the same party to do.
GET /call/{token} for outgoing calls. It is what a link clicker would
access to find out who he is about to call. Consider the case in which
you send me a link and Eric sends me a link, and I save them off for
later use. Then, at some point in the future, I try to call you with the
link, but get the wrong one. This is the call that is going to allow the
link-clicker interface to tell me that I'm about to call Eric instead of
you.
GET /calls?version= is to get information for incoming calls.
Extra Call Information
--
According to
https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#call-incoming-unknown
we should have the date the url was generated - I don't see that in
the docs currently.
Good catch. Thanks.
Which Calls
--
Should we also change /calls?version= to only ever return one call?
Currently if two incoming calls came in close together, we'd be
getting duplicate information for the second call.
The list of calls at any given moment should only include those calls
that are currently in an alerting state -- that is, they've been
initiated, but the caller hasn't abandoned the call; the caller has
neither accepted nor rejected the call; and the server has not timed-out
the call.
In other words, the only way you'll see two records is if two people are
actively sitting around waiting for you to answer their calls. And, in
that case, I think we're going to want to tell the user that they have
two incoming calls right now, and give them the ability to answer the
one of greater interest to them.
In other words, the calls you get from /calls?version= should ideally
represent only those calls that are in active setup at the moment.
Call URL generation and identification
In POST /call-url I believe the callerId parameter should now become
optional or removed, as the user may or may not specify it.
The discussions with Darrin so far have included ideas like having the
client put randomly selected names (e.g., adjective/animal pairs) in
when the link generator does not specify one.
Although, I'm actually a bit puzzled, as I thought in an earlier
version of the document, you could specify the caller id and duration
separate to getting the call url, but this seems to have been lost.
That's what POST /call-url/{token} does -- it allows adjusting URL data
after the fact. So, for automatic generation, the client uses POST
/call-url/ with information that it automatically selects (i.e.,
without user intervention). The user can then, if he so chooses, modify
that preselected information, which causes a POST /call-url/{token}
call to update the information on the server.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: Loop Server MVP: Protocol and Architectural Enhancements
On 6/16/14 14:50, Tarek Ziadé wrote: Le 16/06/14 11:54, ale...@mozilla.com a écrit : .. Maximum Simultaneous Connections 11,656,238 Current max sockets connections on an EC2 host is 250K. This means we'll need approx. 46 servers to handle the long term max sim. connections. ... This seems to be a lot of servers (for 500M users). It seems unrealistic to consider that 500M users will use Loop imho. Shouldn't we base this on the number of weekly active users maybe ? At the beginning of the project, when we were setting up parameters around what the architecture should be designed for, 500M was the top-line number I was instructed to use. Not that we expect to have this many ever -- it would make us the second-largest telecom operator in the world -- but if the architecture cannot scale beyond this number, we consider that an acceptable limitation. The important thing, from a mid-term perspective, is that we need to be able to scale to more than one server if we get 11M or 12M users; and the design very much takes this into account, by allowing scaling across multiple servers. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Loop Server MVP: Protocol and Architectural Enhancements
), but it's not clear to me what this is specifically. Can you elaborate? I don't understand why this needs to be relayed by the server. It needs to be relayed by the server because the endpoints don't have any other way to communicate with each other. The point is to supervise call setup to the point that both endpoints are satisfied that the call is established. To have a polished UX, we need this information so that reasonable progress and error information can be rendered to the user. Offered traffic 0.1 Erlang per subscriber Is this a typo? I don't understand the meaning. No, it's not a typo -- it's an estimate of the peak traffic generated on a per subscriber basis. Erlang is a unit of voice traffic load (see https://en.wikipedia.org/wiki/Erlang_%28unit%29). Reasonable values for offered traffic are generally in the range of 0.05 to 0.15 Erlang per subscriber (and I suspect ours will be on the lower end of this), so I picked a value somewhere in the middle. I'm including my assumptions here in case someone with a telecom traffic engineering background wants to double-check my work. Transition While the (lack thereof) concerns you're raising are valid, it doesn't seem to make sense to avoid flag days for something that's MLP and only released in nightly. e.g. in case it breaks, I believe we should just let it break for now and focus on getting the new APIs right rather than having backwards compatibility at this stage of the project. I suppose a large portion of this depends on how quickly the change can be made to the server, and how many users are experimenting with the service at that time. In any case, given how little effort it would be to keep the already issued URLs valid, I see no reason to rip out working code rather than simply moving it behind a length check. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Loop Server MVP: Protocol and Architectural Enhancements
For those of you working with Loop, I'm looking for feedback on some API and architectural enhancements necessary to satisfy our MVP use cases. Although there is still work remaining, the first three major sections of this document are functionally complete and ready for review: https://wiki.mozilla.org/Loop/Architecture/MVP Note that this URL is a temporary scratch area for this work. Once it is more baked, the intention is to move it to a more final location within the main Architecture document and/or the Loop Server API documentation. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: No WebRTC team meeting this week (so we're free to attend the Town Hall about the FxOS goals for 2014)
On 4/21/14 15:17, Maire Reavy wrote: NOTE: If there are any important heads up notifications for the team or any blocker issues/questions that you would have raised in the face-to-face, please respond to this thread with what you would have said. I'm on PTO this upcoming Friday and the Friday following. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/24/14 05:07, Alexis Métaireau wrote:
That's interesting, because I had something in mind that I haven't
made explicit: because the token server returns nodes to use for the
users, I was planning on using this in order to avoid charging the
load balancers. e.g. something like this (Bob wants to be called):
1. Temp URL is generated by the server for Bob. This URL is tied to a
node, e.g. https://node42.loop.services.mozilla.com/call/{token}
2. Bob gives this URL to Alice in order to be called
3. Alice clicks on the link and the node know what's the format of the
token because /node42/ runs only this version of the service.
As long as the version of the service is valid, node42 is up, and when
this is not valid anymore we can ditch it.
Sure, that does effectively the same thing with the load distribution
advantage you describe. I'm perfectly happy binding the token syntax to
the authority name like you suggest.
However, this approach doesn't work well in the case we want these
temporary URLs to be persistant (the b. case).
If we're handing out different servers for different format versions, we
can defer this until we actually deploy permanent tokens (assuming we
eventually decide to do so). In other words, the permanent tokens will
need to be at a different authority (machine), and we can use versioning
for that machine's URLs only.
So let's go with what you propose, and we can worry about putting
versions in the URL path when and if they become necessary.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/21/14 11:58, Romain Testard 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. Because of the mechanism I'm proposing for revocation, the URLs we're generating right now will be time-limited. This can be a relatively long time period, like on the order of a month, but not indefinite. So, you can go ahead and shorten these URLs with a service, but the shortened URL's period of validity will be bound to the longer URL's period of validity, unless the service allows you to update the long URL associated with a short URL. That said, because we have an indicator of the token format (the version in my original email on this topic), it's very easy to bolt on permanent call-me URLs at a later date, once we know how they need to behave. But how they need to behave is actually much trickier than it appears at first glance; in particular, the revocation story gets murky: if you've given mz.lo/romain out to hundreds of people, revocation is a pretty extreme measure, akin to changing a phone number. And we almost certainly don't want to roll permanent URLs out without some kind of revocation, as this could make the service functionally useless for people: would you continue to use the service if you started getting nuisance calls on mz.la/romain as frequently as you get email spam? So I think the important thing to note is that we don't support what you propose right now, but we do have specific architectural hooks that will allow us to add it at a later date once we better understand the requirements. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/20/14 04:54, Alexis Métaireau wrote:
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
Sure, for most of the HTTP interactions, this is true, and it's a good
principle in general. The way I was viewing this was that the handed-out
call URLs (unlike other operations we're performing) weren't going to be
idempotent: accessing the resource twice would create two calls. In
traditional HTTP design, this would typically be relegated to something
like POST, but we can't pass around URLs with an embedded method in a
well-supported way.
That said, I see that the GET/POST proposal you have addresses this in a
more resource-based fashion, and agree that it's a cleaner way to handle
URLs.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme...
# A * means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a call me URL and (if possible) deliver
it using the contact means (email or phone/SMS) corresponding to the
address book entry. So, when we create the URL, we'll know who the user
intends to give it to.
This is important because it allows us to say You have an incoming call
from Alexis rather than You have an incoming call from some random
person. The delivery of calling party identity is simply considered
table stakes for a communications service nowadays [1].
In your proposal, I don't understand what is the serial #, and
especially why it can't replace the version as you specify it.
The serial number is different for each and every URL issued, and is
used for revocation purposes.
The version allows us to transition between schemes in the future, if
we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The same
goes if we decide to add fields, encode them differently, or even go to
a completely different design (such as a sparse key into a database
table). It gives us an out to reconsider the design of the token if it
doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature of
the system, not a problem: the check for revocation of a serial # is
part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
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.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple versions
Architecture Decisions and Action Items for User-Facing WebRTC Project
(Sorry for the long subject -- I think we have a project name picked out, but since it hasn't been officially communicated yet, I'm using the descriptive term User-Facing WebRTC Project.) Based on conversations this morning, we have a number of decisions and pending action items for the user-facing product architecture. These are summarized below. I've marked action items with a single letter to indicate the associated timeframe: L for MLP, and V for MVP [1]. I have action items recorded for Mark Banner, Nicolas Perriault, Dan Mosedale, Eric Rescorla, Alexis Metaireau, and myself. Client Architecture Decisions * The panel JavaScript will ship with the browser and ride the trains, at least through MVP. * Local data storage will make use of the IndexedDB API. We may choose to wrap it to make it less painful to use. * Unit testing of client code will be performed with the mochi test framework. Action Items * L: *Adam* to contact Gavin, Dolske, and Shane to determine future availability and support for Social API * L: *Mark* to experiment with loading chrome: URLs in the Social API to determine whether doing so gives us sufficient elevated privileges. * L: *Nicolas* to examine use of client libraries (jQuery, Backbone) to determine how much effort we're likely to save versus the effort of ensuring we can run the libraries safely in the context of elevated privileges. * V: *Adam* to research possibilities for running part of the code with chrome privileges and others with content privileges, so as to minimize the exposure to security issues. * V: *Dan* to evaluate the use of templates for the use of l10n (will all WebRTC browsers have template support?). * L: *EKR* to touch base with Doug to determine tools used to test Sync, evaluate applicability to our use cases. * L: *Adam* to contact David Burns and Ted to determine the level of effort it would take to make Marionette and Steeplechase work together, to facilitate system testing. * L: *Adam* to ask Ted who to contact regarding the prospect of running a subset of Mochi tests on Chrome/Chromium. * L: *Adam* to talk to Andreas and Denelle about partner library code landing and versioning. Server Architecture Decisions * Development will be performed in node.js * No external libraries are identified for use at this time. Any external libraries will be discussed and agreed upon before importing. * Current assumption is that we will use AWS for deployment. This can be revisited if circumstances arise that makes that deployment environment suboptimal. o As an aside, the ability to run the server code locally is a hard requirement. * We will use github pull requests to ensure that patches are reviewed prior to landing. Action Items * L: *Adam* to task appropriate party with evaluation of available databases. * L: *Alexis* to create repo in under mozilla github; *Adam* to send him list of team members so they can be added to the committers. * L: *Mark* to investigate state of github/bugzilla integration. [1] That's Minimum Landable Product (aka demo) and Minimum Viable Product for anyone not used to these acronyms. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
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 three fields together, prepended with a
serial number (1 in this example):
secret = Bjqcy:FCwn^1P.s,v9,+;9AN(w%X$:
state = 1:a...@mozilla.com:a...@nostrum.com:1393730353
hmac = HMAC_SHA265(secret, state) % 0x1 = 0x7a4a77ba
call_string = base64(concat(state, hmac)) =
MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6
This would then be combined with the authority
(loop.services.mozilla.com), the action (call) and the version (1)
to create the following url:
http://loop.services.mozilla.com/call/1/MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6
(n.b., we probably want to strongly obscure the fields inside the blob
so as to avoid the ability to back out a called-party's contact
information -- a...@nostrum.com in this example -- but for MLP, this
should be sufficient)
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/19/14 22:32, Martin Thomson wrote: 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 You'll note that I employ pretty much that technique exactly, modulo the encryption (which I call out in the final paragraph as not in this version, but probably desirable for the next, and which the draft concedes is optional) and the use of bitmasks and bloom filters for invalidation (since revocation is expected to be exceedingly rare). 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. Apparently, I was not sufficiently clear. I was not describing client behavior in any way whatsoever. I was describing server behavior. The intention here is exactly that the client asks for a full URL, and the server provides one. The client is in no way involved in synthesis of the URL. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: mozilla, webrtc and TURN server
On 1/29/14 04:36, Ijatsu wrote:
I give to webRTC a set of 2 TURN server address...
How are you passing these to the PeerConnection? Chrome started out
using a non-standard format along the lines of:
{ iceServers: [ {url: turn:username@host, credential: password } ] };
Firefox uses the format specified in the evolving standard, which Chrome
now supports as well:
{ iceServers: [ { url: turn:host , username: username , credential:
password} ] }
If you try using the first format, then Firefox cannot find the
username, and will not attempt to authenticate itself to the TURN server.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: ICE-TCP and BUNDLE
On 12/14/13 13:42, bryandonno...@gmail.com wrote: When broadcasting to a large audience, 1 sec latency is nothing, and packets are not dropped on the floor. Indeed. I do, then, wonder why you would want to use WebRTC, rather than an icecast-style setup using streaming HTTP. What you describe isn't real-time (at least, not in the way WebRTC uses that term), so WebRTC doesn't really seem like the right tool. In fact, your application seems like it would benefit greatly from the kind of multi-second buffering that we would consider to be wildly unacceptable for WebRTC. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: webRTC and cisco openH264
On 12/13/13 14:59, Bo Xu wrote: could you tell me if there is any schedule for Firefox support Cisco openH264? Not yet. The plan is as soon as possible. There's a lot of work going on right now to make that happen, but I don't think we can provide a time estimate yet. I have tested the openH.264 codec itself, but I am not sure when Firefox will include it: will Mozilla update webRTC first to handle H.264? I'll let someone else answer that, as I'm not entirely sure how we're hooking into the video engine. and do users need to download openH264's binary from Cisco when they install Firefox? or Mozilla will include openH264's binary inside the new version of Firefox? Thanks! Users will not need to take any additional actions, and shouldn't notice any difference in behavior. Firefox will automatically download the codec binary from Cisco's servers. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Live video streaming for Firefox OS?
On 10/25/13 16:40, Felix E. Klee wrote: On Fri, Oct 25, 2013 at 10:16 PM, Chris Double chris.dou...@double.co.nz wrote: You should be able to stream Theora or WebM videos using Icecast or similar: http://icecast.org/ And client-side? Note that I'm talking about *live* video streaming. As far as I know, there's nothing about icecast that would get in the way of doing (nearly) live streaming of video. For example, see this page: http://current.workingdirectory.net/posts/2012/vp8-and-debian/ Now, if you don't mind getting your server to deal with SDP, SRTP/DTLS, and ICE (or ICE LITE), then WebRTC could certainly be used for low-latency live streaming. You'll probably find yourself doing quite a bit of custom development for this, at least, in the short term. But should certainly be feasible. I believe the current roadmap has WebRTC landing in FirefoxOS 1.3. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Live video streaming for Firefox OS?
On 10/25/13 16:59, Felix E. Klee wrote: On Fri, Oct 25, 2013 at 11:50 PM, Adam Roach a...@mozilla.com wrote: low-latency live streaming. Actually, latency isn't a big issue, as long as it's no more than say a second. Yeah, an icecast-like thing is probably the way to go, then. Once you get your server set up, this is extremely easy to use in a webpage. For example, drop this into an HTML file: video width=160 height=100 src=http://radioserver1.delfa.net:80/256.opus; controls/ Now, if that URL pointed to an icecasted VP8 stream instead of an icecasted opus stream, you'd be watching video instead of listening to extremely smooth jazz. (Sorry, I can't find a good video example at the moment.) Would this be an interim solution, or is WebRTC the future for video live streaming? I'm new to this field. Only Icecast I have used years ago to set up an audio live stream (mobile phone - SIP - IceCast - MP3 stream). WebRTC is designed for real-time communications, which you can basically model as those use cases that require ~100ms one-way (~200ms round-trip) delay or less to work. This is required, for example, to have a conversation between two people. (WebRTC is also quite important for doing direct browser-to-browser communication, but that doesn't seem to have much bearing on what you're doing). These capabilities do come with a certain level of complexity, however. Given that you don't need sub-second latencies, you're probably better off just doing an icecast approach. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: MediaStream constructor
On 10/23/13 12:41, hendersonpho...@gmail.com wrote: If it's possible, how do I construct a MediaStream in firefox without calling GetUserMedia? You can't. The only specified way to procure one is via the success callback of getUserMedia (representing a local camera and/or microphone) and through the onaddstream callback from RTCPeerConnection that's triggered by calling setRemoteDescription (representing remote media received over the network). The idea behind a MediaStream is that it represents some kind of *source* that you're going to attach to something. If you were to somehow manage to construct one in a vacuum, what source would you expect it to represent? In other words: what are you trying to do? -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: PeerConnection.removeStream
On 10/23/13 15:34, Tom Hughes wrote: It appears that PeerConnection.removeStream is not yet implemented. The code refers to https://bugzilla.mozilla.org/show_bug.cgi?id=844295, but that bug is targeted towards implementing the current behavior where removeStream throws an exception since the underlying functionality doesn't work. Is there a bug that tracks the dependencies to make it work? This is considered part of the whole renegotiation functionality, which is being tracked in Bug 857115: https://bugzilla.mozilla.org/show_bug.cgi?id=857115 See also https://hacks.mozilla.org/2013/09/webrtc-update-and-workarounds/ -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Question on DTLS roles
On 9/18/13 17:22, Rajarshi Chaudhuri wrote: Hi - I'm using FF nightly 26 and 27 for WebRTC. And things are not exactly peer-to-peer - as we have our own Media Gateway in between. It seems like FF nightly assumes the DTLS client role regardless of who is the caller? Yes, we had a regression here that didn't get caught until late in the cycle. See https://bugzilla.mozilla.org/show_bug.cgi?id=917619 Also FF nightly does not seem to respect the setup attribute in the SDP answer (though it has the setup attribute in its own offer SDP with the value actpass indicating that it's willing to assume either role). That is a different problem, and not one that I've seen. Can you send me a copy of the offer and the answer so I can try to figure out what's going wrong here? -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: ice-lite support
On 7/31/13 11:33, pablo.pl...@gmail.com wrote: Does Firefox support ice-lite? I would Firefox to interwork with an ice-lite implementation just fine. If you find any issues with doing so, please let us know. Is there a reason not to use ice-lite when building MCU? Using ICE Lite in an MCU is probably okay in the majority of deployment scenarios, since they will generally be deployed in non-NATed, non-firewalled configuration. Do be aware, however, that implementing your MCU with ice-lite does impose on it the limitation that it will work only in those kinds of deployments. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: How to turn on WebRTC debug logs on Firefox?
On 7/9/13 13:29, prakashr.i...@gmail.com wrote: In Chrome, we can turn on detailed debug logs to see ICE connections, STUN pings and other media related logs, Is there instructions somewhere for how to do this in firefox? I don't know of any detailed instructions anywhere, but logging in Firefox in general is controlled via environment variables. For ICE/STUN/TURN: Set R_LOG_DESTINATION=stderr Set R_LOG_LEVEL=3 (can be anything between 1 and 9) Set R_LOG_VERBOSE=1 if you want to include the module name generating the message For signaling (SDP offer/answer handling) and media transport, we use the normal Mozilla logging infrastructure, which uses a comma-separated list of modules, each one with its indicated log level; for WebRTC, you'll be most interested in these: Set NSPR_LOG_MODULES=signaling:5,mtransport:5 You can also add ,timestamp:1 to that list if you want each log message to include timestamps. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onicecandidate plan
On 7/2/13 21:43, Iwan Budi Kusnanto wrote: Is there any plan to implement onicecandidate in firefox? If yes, when it will be? I presume your question is whether and when Firefox plans to implement trickle ICE, since we already do call onicecandidate once (with a null candidate) after the local description is set. Trickle ICE is definitely planned. I can't give you a date or target release, since trickle ICE is a relatively low priority: it is simply a minor timing optimization, and does not (for example) improve interoperability or NAT traversal. If you're interested in following this issue once work starts on it, add your name to the CC list for this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=842549 -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: changing ice credentials in answer
On 6/26/13 11:39, bryandonno...@gmail.com wrote: Is it possible to modify the ice-ufrag and ice-pwd in the SDP returned by createAnswer? It has no effect when I modify the SDP before calling setLocalDescription. Is this a known issue? Should I file a bug? See https://bugzilla.mozilla.org/show_bug.cgi?id=784514 However, note that the W3C has not yet determined what parts of SDP the scripts are allowed to edit, and which parts are immutable. If we had the conversation today, I'm pretty sure the ufrag and password would not be considered candidates for editing. To put a finer point on it: I'm probably the one who will be implementing the SDP editing handling, and I did not plan on allowing these values to be changed. Can you explain why you would want to do this? -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Does FF supports h264 RTP packetization?
On 6/24/13 04:39, tao siping wrote: I heard some news that firefox already supports native h264 encoder/decoder, that is really great. My question is does firefox also support rtp packetization for h264? No. Currently, both Chrome and Firefox use VP8 as the only video codec for WebRTC. There are some thorny IPR issues involved here -- even more than for video playback -- which can cause problems for free software, for both senses of the word free. The licensing fees cause problems for gratis software, while the restrictions inherent in licensed IPR cause problems for libre software. As far as I know, the most recent public statement on the topic is a blog post from Mozilla's CTO, Brendan Eich: We are taking the fight for unencumbered formats to the next battlefront, WebRTC, also as promised. More on that front later. (see https://brendaneich.com/2012/10/html5-video-update/). -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: In onaddstream-Handler, 'this' does not equal the corresponding RTCPeerConnection-Object
Prior to the landing of https://bugzilla.mozilla.org/show_bug.cgi?id=823512, the callbacks were all spoofed using normal function calls rather than event processing. This has several implications, one of which is the behavior you describe below. The patch for that bug has landed on Firefox 24 already. Please re-try your testing on a recent version of Nightly and let us know whether you see any unexpected behavior: http://nightly.mozilla.org/ This fix should make it into Aurora next week, Beta in early August, and the full release version of Firefox in late September. /a On 6/21/13 08:16, Kai Schreyer wrote: When I log the 'this'-Object inside of the onaddstream-Handler to the console, instead of observing it in Firebug, I can see that it equals the onaddstream-Function. But I am still of the opinion, that 'this' (inside of the onaddstream-Handler) should refer to the corresponding RTCPeerConnection-Object. Right? Cheers Kai ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Test Day on June 21st
On 6/17/13 16:36, Jason Smith wrote: Hi Everyone, On Friday June 21st, QA will be organizing a test day for WebRTC on Desktop Firefox and Firefox for Android. See http://aaronmt.com/blog/2013/06/17/webrtc-testday/ for more information. I would greatly appreciate if you can jump into the #testday channel this Friday to help answer questions we will get... That shouldn't be a problem. In looking at the blog entry, I'm a bit worried about the phrase ...ensure that all feature functionality that is included in this upcoming release is on its way to a feature and testing complete state. It implies that Nightly contains code that is some substantial portion of the way -- say, more than 50% -- to being feature complete. I think that's misleading. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Reflection Comments from a Recent Experience of Building Three End to End WebRTC Web Applications
On 5/21/13 07:29, Eric Rescorla wrote: * In the process of building an interoperable WebRTC application between Chrome and Firefox, when I did not provide DtlsStrpKeyAgreement to true as an optional constraint to Chrome, Firefox would fail to establish the handshake by reporting an error of DCB has not been created during the addIceCandidate function. Why is this the case? There seem to be several questions. - Why doesn't it work? Because the offer without DTLS is incompatible with Firefox, which requires DTLS. - Why is there a lame error message? File a bug. Please do file a bug on this, with a repro test if you have one. The DCB has not been created message should be impossible to trigger from content javascript, no matter what you're calling, no matter what parameters you're sending in. This is likely indicative of a more serious bug than just an inscrutable error message. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: Does Firefox support stun yet?
Yes. If you don't specify a server, it'll use Mozilla's STUN server by default. At least, for now. You might need to be running Aurora or Nightly for this to work properly. Also, we don't currently take DNS names for STUN servers, although we're working on it at the moment. /a On Mar 1, 2013, at 19:10, Eric Davies ericthecycl...@gmail.com wrote: I haven't found any demos that work when one peer is behind a NAT. Does Firefox support STUN yet? Eric. ___ 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
