Review of WebRTC 1.0 from Web Applications Working Group

2015-10-15 Thread Stefan Håkansson LK
Dear Web Applications Working Group,

The WebRTC Working Group is working toward publishing the WebRTC 1.0 
specification to Candidate Recommendation and is thus seeking review 
from a variety of groups on the document:

http://w3c.github.io/webrtc-pc/

We are particularly interested on feedback on the following aspects from 
the Web Apps WG:
- proper usage of WebIDL; in particular, the WebRTC API has now a 
dependency on the maplike<> construct which is not part of the 
/TR/webidl-1/ spec at the moment,
- the DataChannel API which is heavily inspired from the WebSockets API,
- the overall approach to error handling,
- the instantiation of a worker to interact with a third party system, 
as defined in the Identity section

We of course also welcome feedback on any other aspect of the specification.

Any such feedback received the week before TPAC would make it possible 
for us to look at it during our F2F there and so would be appreciated. 
We hope to transition request to Candidate Recommendation by the end of 
this year.

If you have any comments, we prefer you submit them as Github issues:
https://github.com/w3c/webrtc-pc/issues
Alternatively, you can send your comments by email to public-web...@w3.org.

Thanks,

For the WebRTC co-chairs,
Stefan



Re: Missing Features: Stream Control

2013-10-18 Thread Stefan Håkansson LK
On 10/18/13 6:57 PM, Aymeric Vitte wrote:
 Should this not be synchronized with the Streams API? Please see recent
 evolutions [1] and thread [2] (where WebRTC streams are mentioned)

I think we're talking about completely different streams, and what Adam 
is proposing is applicable for MediaStreamTracks in the context of a 
WebRTC PeerConnection.


 Ccing Webapps and Takeshi/Feras.

 Regarding your proposal I was about to propose to add about the same
 thing in Streams: at least a stop method (which would send an EOF) and
 maybe a resume method, or something like your pause/unpause.

 For flow control I think I am changing my mind, it looks impossible to
 do a precise flow control with js, so probably the API itself should
 handle it.

 Regards,

 Aymeric

 [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html
 [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html

 Le 18/10/2013 18:24, Adam Roach a écrit :
 We've recently had some implementors reach out to ask about how to do
 certain things with the WebRTC interfaces, and I've been pretty well
 unable to turn up anything that makes a lot of sense for most of the
 interesting stream-control interfaces.

 Some of this is talked about here, with an implication that the author
 of this wiki page, at least, would be willing to leave some of them
 unspecified for the first version of WebRTC:

 http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions

 Unfortunately, I don't think we can leave stream pause/unpause or
 stream rejection/removal out of the first version of the document. The
 good news is that I think we have all the interfaces necessary to do
 these things; we just need to spell out clear semantics for them.

 As a high-level thumbnail sketch, here's what I think makes sense:

  1. To pause a track that you are sending, set enabled=false on a
 MediaStreamTrack that you have added to a PeerConnection. This
 information will cause the PeerConnection to stop sending the
 associated RTP. Maybe this triggers an onnegotiationneeded to set
 the corresponding m-line to recvonly or inactive and maybe it just
 stops sending the stream; I'm not sure which makes more sense.
   * To unpause, set enabled back to true, and the steps are reversed
   * To pause all the MSTs associated with a MediaStream, use
 enabled on the MediaStream itself.

  2. To pause a track that you are receiving, set enabled=false on the
 MediaStreamTrack that you received from the PeerConnection via
 onaddstream. This will cause the MST to stop providing media to
 whatever sink it has been wired to, and trigger an
 onnegotiationneeded event. The subsequent CreateOffer sets the
 corresponding m-line to sendonly or inactive, as appropriate.
   * As above, this operation can also be performed on a
 MediaStream to impact all of its tracks.

  3. To reject a track that has been offered, call stop() on the
 corresponding MediaStreamTrack after it has been received via
 onaddstream, but before calling CreateAnswer. This will cause it
 to be rejected with a port number of zero.

  4. To remove a track from an ongoing session, call stop() on the
 corresponding MediaStreamTrack object. This will (a) immediately
 stop transmitting associated RTP, and (b) trigger an
 onnegotiationneeded event.
   * If both the sending and receiving MST associated with that
 m-line have been stop()ed, then the subsequent CreateOffer
 sets the port on the corresponding m-line to zero.
   * If only one of the two MSTs associated with that m-line has
 been stop()ed, then the subsequent CreateOffer sets the
 corresponding m-line to sendonly, receiveonly, or inactive, as
 appropriate.

 Does this make sense to everyone? It seems pretty clean, easy to
 specify, and reasonable to implement. Best of all, we're not changing
 any currently defined interfaces, just providing clear semantics for
 certain operations.

 /a


 --
 Peersm :http://www.peersm.com
 node-Tor :https://www.github.com/Ayms/node-Tor
 GitHub :https://www.github.com/Ayms





Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 01:29, Robert O'Callahan wrote:
 What are your use-cases where they're not the same? More importantly,
 what are the use-cases where they cannot be made the same by the developer?

E.g. the main page delegating communication to someone else (perhaps via 
an iFrame). If the MediaStream is a transferable object the incoming 
MediaStream can be transferred to the main page, which in turn can 
control layout and rendering.


 Rob
 --
 Jtehsauts  tshaei dS,o n Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
 eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o  Whhei csha
 iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  sGients  uapr,e
 tfaokreg iyvoeunr, 'm aotr  atnod sgaoy ,h o'mGee.t  uTph eann dt hwea
 lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
 *




Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 12:01, Harald Alvestrand wrote:
 On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:
 On 2013-09-03 01:29, Robert O'Callahan wrote:
 What are your use-cases where they're not the same? More importantly,
 what are the use-cases where they cannot be made the same by the developer?
 E.g. the main page delegating communication to someone else (perhaps via
 an iFrame). If the MediaStream is a transferable object the incoming
 MediaStream can be transferred to the main page, which in turn can
 control layout and rendering.

 One interesting thing about a MediaStream is that it's got multiple
 links to the world around it. In particular, it can be connected to
 multiple downstream objects.
 This means that what happens to its peers when one transfers it has to
 be defined.

 For instance, if MediaStream were transferable, could I do this?

 GetUserMedia(., success, failure)

 function success(stream) {
  myVideoTag.srcObject = stream
  stream.transfer(myWorker)
 }

 and after this - would the video stop playing (because the stream is
 gone from my context), or not?

I think it should stop playing since the object srcObject references is 
gone. (It would work differently with createObjecURL + myVideoTag.src 
since that would only be a handle to an underlying resource)

If you'd like it to continue playing you'd have to clone the MediaStream 
and transfer the clone.








Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 14:02, Anne van Kesteren wrote:
 On Tue, Sep 3, 2013 at 12:48 PM, Stefan Håkansson LK
 stefan.lk.hakans...@ericsson.com wrote:
 I think it should stop playing since the object srcObject references is
 gone. (It would work differently with createObjecURL + myVideoTag.src
 since that would only be a handle to an underlying resource)

 The object is not gone, it's neutered. That could mean e.g. that
 instead you'd get black and no sound. Kinda depends on how you define
 a neutered MediaStream to work.

Right. I should've known. Thanks.







Re: Extending createObjectUrl to MediaStream?

2013-09-02 Thread Stefan Håkansson LK
On 2013-09-02 01:44, Robert O'Callahan wrote:
 On Sat, Aug 31, 2013 at 1:14 AM, Stefan Håkansson LK
 stefan.lk.hakans...@ericsson.com
 mailto:stefan.lk.hakans...@ericsson.com wrote:

 One need I can see is when you want to display the video in another
 window. Let's say you want to have the video in a popout window -
 something I think we should definitely support - handing that window the
 URL (using postMessage) for use by its video element is a very
 convenient way to support this use-case. This works in Chrome today.


 Assuming the main window opened the popout window, and both pages have
 the same origin, this can be done without createObjectURL or any new
 features, because the main window has access to the DOM of the popout
 window (and vice versa).

Yes, but I don't think we should constrain this to only meet cases when 
the origin of the other window is the same.


 Rob
 --
 Jtehsauts  tshaei dS,o n Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
 eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o  Whhei csha
 iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  sGients  uapr,e
 tfaokreg iyvoeunr, 'm aotr  atnod sgaoy ,h o'mGee.t  uTph eann dt hwea
 lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
 *




Re: Extending createObjectUrl to MediaStream?

2013-08-30 Thread Stefan Håkansson LK
On 2013-08-28 17:48, Dominique Hazael-Massieux wrote:
 Hi WebApps WG,

 The Media Capture Task Force (responsible for specs that deal with
 MediaStream objects [1]) has been considering whether one should be able
 to assign a MediaStream to video and audio elements via an URL
 obtained via createObjectURL or not, and is seeking feedback on the
 question.

 More precisely:
 A. we define a new srcObject attribute on HTMLMediaElement objects that
 can take directly a MediaStream object and make it playable
video.srcObject = mediastream;
 B. the spec also supports assigning a MediaStream via the src attribute,
 via an URL obtained through createObjectURL:
   video.src = URL.createObjectURL(mediastream);

 While there are ongoing discussions on how to spec B properly [2] (which
 will require coordination with the WebApps Working Group), we are first
 and foremost wondering if that option is needed at all.

 We are thus looking for input on the use cases for createObjectURL as
 used for the File API, and whether these use cases would also apply to
 our MediaStream case. In general, is there a need for any object
 readable by media elements to support an URL-based approach for
 consistency with the rest of the platform?

One need I can see is when you want to display the video in another
window. Let's say you want to have the video in a popout window -
something I think we should definitely support - handing that window the 
URL (using postMessage) for use by its video element is a very
convenient way to support this use-case. This works in Chrome today.

But, an alternative could perhaps be to make MediaStream a transferable 
(which means that the MediaStream object could be sent over using 
postMessage IIUC).


 Thanks!

 Dom for capture-ACTION-23

 1. http://dev.w3.org/2011/webrtc/editor/getusermedia.html
 2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594








Ericsson referred patents vs Web Sockets API and Server-Sent Events

2009-09-16 Thread Stefan Håkansson LK
Hi all,

some of you may remember that Ericsson when joining the WebApps WG made a 
reference to patents US 6,321,250, EP1310114 and PCT/EP2008/064352 (not yet 
published). Someone may have assumed Ericsson would disclose or even exclude 
from W3C RF licensing as defined in the W3 Patent Policy some claim of these 
patents in relation to the Working Draft Web Sockets API or Working Draft 
Server-Sent Events.

We have neither disclosed nor excluded any of the claims of these patents in 
relation to the Web Sockets API or the Server-Sent Events Working Drafts 
because we believe that there is no claim that is an Essential Claim to 
WebSockets API or Server-Sent Events Working Drafts as defined in the W3C 
Patent Policy. Ericsson believes that an implementation of the normative parts 
of either of these Working Drafts does not necessarily infringe any of the 
claims of these patents. In other words, the following part of the definition 
of Essential claims in the W3C Patent Policy is not met: A claim is 
necessarily infringed hereunder when it is not possible to avoid infringing it 
because there is no non-infringing alternative for implementing the normative 
portions of the Recommendation.

Stefan Håkansson, on behalf of Telefonaktiebolaget LM Ericsson