January 2011 - RTC-Web - alvestrand.no

Does RTC-WEB need to pick a signaling protocol?
by Jonathan Rosenberg 15 Mar '11

15 Mar '11

I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net

13 19

Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
by Adam Roach 01 Feb '11

01 Feb '11

On 1/29/11 8:35 AM, Jonathan Rosenberg wrote: > I'm starting a separate thread on this, since I don't want to confound > it with the charter discussion. This is a topic that should be > resolved within the group itself I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other. Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach? /a

9 9

The charter formerly know as RTC-WEB take 3
by Cullen Jennings 31 Jan '11

31 Jan '11

In my dispatch co-chair role, I tried to take all the comments I had seen on the list about this charter and see if I could address them in a new version of the charter. I probably messed up in some places. There were some conversation that did not seem to be converging so I did not make any changes for theses. Have a read and if you think something needs to be changed, propose text changes along with the reasons why and we will keep the evolving this charter. Thanks Cullen ---------------------------------------------------------------------------------- Version: 3 Possible Names: RTCWEB WEBRTC STORM: Standardized Transport Oriented for Realtime Media BURN: Browsers Using Realtime Media WAVE: Web And Voice/Video Enablement WAVVE: Web And Voice Video Enablement REALTIME WEBCOMM WREALTIME WEBTIME WEBFLOWS BRAVO Browser Realtime Audio and VideO COBWEB COmmuication Between WEBclients WHEELTIME Body: Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the web server acts as the signaling path between these applications, using locally significant identifiers to set up the association. Up till now, such applications have typically required the installation of plugins or non-standard browser extensions. There is a desire to standardize this functionality, so that this type of application can be run in any compatible browser and allow for high-quality real-time communications experiences within the browser. Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human. The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming. This working group will select and define a minimal set of protocols that will enable browsers to: * have interactive real time voice and video pairwise between browsers or other devices using RTP * have interactive real time application data for collaboration and gaming pairwise between browsers Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set: 1) RTP/ RTCP 2) a baseline audio codec for high quality interactive audio. Opus will be one of the codecs considered 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be some of the codecs considered 4) a baseline video codec. H.264 and VP8 will be some of the codecs considered 5) Diffserv based QoS 6) NAT traversal using ICE 7) media based DTMF 8) support for identifying streams purpose using semantics labels mappable to the labels in RFC 4574 9) Secure RTP and keying 10) support for IPv4, IPv6 and dual stack browsers Please note the above list is only a set of candidates that the WG may consider and is not list of things that will be in the profile the set. The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the state of DTLS/SRTP handshakes. The output of this WG will form input to the W3C group that specifies the API. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource Priority. RTP Payload formats will not be done in this WG. Milestones: May 2011 Main alternatives identified in drafts Aug 2011 WG draft with text reflecting agreement of what the profile set should be Sept 2011 Scenarios specification to IESG as Informational Nov 2011 Documentation specifying mapping of protocol functionality to W3C-specified API produced. This is an input to W3C API work. Dec 2011 Profile specification to IESG as PS Apr 2012 Mapping W3C defied API to IETF protocols to IESG as Informational. This depends on the W3C API work.

23 54

Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
by Henry Sinnreich 30 Jan '11

30 Jan '11

If XMPP evangelists can commit not make any more pitches for XMPP, maybe the evangelists for SIP (count me in) could reciprocate :-) So, suppose we move on, especially, since application level scripts for both basic SIP and basic XMPP can be written and published as OS by those who really want to. And here we are getting to the key point IMO that both Jonathan and I have mentioned: Leave the field open to innovation. While SIP has been focused on telephony, XMPP has been focused on chat rooms and both, while successful have missed the major innovations on the Web that have happened since, mostly without any new standards: * REST * P2P RT A/V/IM * Web mail * Wikis and blogs * Social networks * Web conferencing * Web office apps and enterprise apps * Cloud services * Streaming HTTP and CDNs, etc, etc. Note that except for P2P RT A/V/IM, mostly basic/core HTTP and HTML standards were used. >From this perspective, it is enough to let SIP and XMPP folks publish their application level scripts and support some mechanism for endpoints to use either or both if so desired. The key however is not to shackle innovators with either SIP or XMPP or both (the worst outcome) as mandatory. Actually, as mentioned here, is not the W3C supposed to specify the API for RT-Web? Thanks, Henry

1 0

Re: [RTW] Does RTC-WEB need to pick a signaling protocol?
by Bernard Aboba 30 Jan '11

30 Jan '11

Just to provide some context for those who may have only recently been exposed to the realtime web. The realtime web is not new -- it has been in operation for more than a decade, as embodied in commercial services such as Adobe Connect, WebEx, Live Meeting, etc. which serve millions of users on a daily basis. The realtime web is supported on virtually every major browser and web server platform. Javascript libraries for signalling are not a "future development" -- they have been around for a while. All that is really new here is the ability to engineer these services without plugins. That's important because it will make realtime web services considerably easier to develop and maintain. However, the "major event" occurred during the early 2000s. _____ Date: Sun, 30 Jan 2011 00:02:59 -0800 From: erik(a)hookflash.com To: jdrosen(a)jdrosen.net CC: rtc-web(a)alvestrand.no; dispatch(a)ietf.org Subject: Re: [RTW] Does RTC-WEB need to pick a signaling protocol? I understand the argument and agree that pure http might be the right course at some point in the future but the fact remains, SIP rules in communications "today", it will do so for years to come. It might be wise for us to move forward on a standard that is understood and appreciated by not only the developer community but also the business community paying the bills. Yes, we can build anew atop http, all it takes is time and money. An http effort will take a while, I think we all know that. How long did it take for SIP to displace H.323? I think the unanimous answer is "too long". We have a standard that exists today, one that we are all very familiar with, one that works! It would seem a shame not to leverage all we (and our employers) have invested, which is considerable. This is a major event in communications, we need to consider this carefully but we also owe it to "standards" to do it quickly, which has not been the norm it seems. Erik Lagerway | hookflash | m. 604.562.8647 On Sat, Jan 29, 2011 at 6:35 AM, Jonathan Rosenberg <jdrosen(a)jdrosen.net> wrote: I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net _______________________________________________ RTC-Web mailing list RTC-Web(a)alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web(a)alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web

1 0

НА: [dispatch] Does RTC-WEB need to pick a signaling protocol?
by Slava Borilin 29 Jan '11

29 Jan '11

+1 Slava borilin, Spirit ----- Reply message ----- От: "Jonathan Rosenberg" <jdrosen(a)jdrosen.net> Дата: сб, янв 29, 2011 17:36 Тема: [dispatch] Does RTC-WEB need to pick a signaling protocol? Кому: "'DISPATCH list'" <dispatch(a)ietf.org>, "rtc-web(a)alvestrand.no" <rtc-web(a)alvestrand.no> I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch

1 0

НА: [dispatch] Does RTC-WEB need to pick a signaling protocol?
by Slava Borilin 29 Jan '11

29 Jan '11

+1 Slava borilin, Spirit ----- Reply message ----- От: "Jonathan Rosenberg" <jdrosen(a)jdrosen.net> Дата: сб, янв 29, 2011 17:36 Тема: [dispatch] Does RTC-WEB need to pick a signaling protocol? Кому: "'DISPATCH list'" <dispatch(a)ietf.org>, "rtc-web(a)alvestrand.no" <rtc-web(a)alvestrand.no> I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch

1 0

Use SIP and let's get on with it already!
by Erik Lagerway 28 Jan '11

28 Jan '11

Come on guys, we all know SIP is bit busted but isn't it also the de-facto standard? Yes, we can debate the pros and cons of this approach until the cows come home but it would be really nice if we could move forward with just one protocol (for now) that will enable immediate usage across the vast majority of all IP networks. A protocol that everyone already knows. 'X'oIP is finally getting close to crossing the chasm, why would we drop in Jingle (or a completely new protocol) and prevent mass adoption sooner rather than later, or worse create yet another silo? Also, proposing only part of the solution will get us nowhere. Jingle might be more monolithic but it's also not the standard. Carriers, providers, vendors & users need this in 2011! Btw, I agree with Adam that this is best handled in the WG but I simply could not resist :) <bracing for impact> -Erik

1 0

Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
by Matthew Kaufman 27 Jan '11

27 Jan '11

Agreed, but for the purpose of this discussion I believe that rate control of some sort should also be a MUST. Web browsers are extremely prevalent, and we hope that RTC use in browsers will be high, and so it would be good for the Internet for browsers to have sending rate control. Note that this is at the protocol level... so send rate must be controlled whether the codec can have its rate adjusted downward so as to not require the protocol level to enforce or not. For interoperability, it is also required that the feedback mechanism from one end to the other be standardized, even if the way that feedback is used to control send rate and/or codec selection or codec rate selection is proprietary and/or extensions to the feedback are also sent for endpoints that understand the (possibly proprietary) extension(s). Matthew Kaufman On 1/25/2011 7:38 AM, Rosenberg, Jonathan wrote: > > It’s a proprietary algorithm of our own design, supported by some > protocols which exchange feedback in real-time between endpoints. > We’re constantly tweaking it based on user feedback and technical > statistics we collect. > > Indeed – as many folks are aware, rate adaptation has always been an > area of innovation and differentiation. RTP has provided the tools for > feedback but has allowed implementations to do whatever they want. I > think it is important that this continues to be the case in the web > world – that folks designing RTC applications can innovate and define > their own versions of these algorithms. > > Thanks, > > Jonathan R. > > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > > Chief Technology Strategist Mobile: +1 (732) 766-2496 > > Skype SkypeIn: +1 (408) 465-0361 > > jdrosen(a)skype.net http://www.skype.com > > jdrosen(a)jdrosen.net http://www.jdrosen.net > >

3 2

ConnectionPeer API experiments
by Stefan Håkansson LK 26 Jan '11

26 Jan '11

Hi all (only rtc-web as it's API related), as promised some time ago, here are some results from implementing and tesing parts of the ConnectionPeer API. (FYI We just submitted a very similar mail on the WhatWG list). We have done some experimentation with the ConnectionPeer API. We have an initial implementation of a subset of the API, using ICE (RFC 5245) for the peer-to-peer handshaking. More information about our work so far can be found here: https://labs.ericsson.com/developer-community/blog/beyond-html5-peer-peer-c… The short story is that ConnectionPeer seem like a good starting point for API discussion. If you want to get into details, continue reading! We have bumped into some details that we'd like to discuss here right away. The following is our mix of proposals and questions. 1. We propose adding a readyState attribute, to decouple the onconnect() callback from any observers (such as the UI). const unsigned short CONNECTING = 0; const unsigned short CONNECTED = 1; const unsigned short CLOSED = 2; readonly attribute unsigned short readyState; 2. We propose replacing the onstream event with custom events of type RemoteStreamEvent, to distinguish between adding and removing streams. attribute Function onstreamadded; // RemoteStreamEvent attribute Function onstreamremoved; // RemoteStreamEvent ... interface RemoteStreamEvent : Event { readonly attribute Stream stream; }; The 'stream' attribute indicates which stream was added/removed. 3. We propose renaming addRemoteConfiguration to setRemoteConfiguration. Our understanding of the ConnectionPeer is that it provides a single-point-to-single-point connection; hence, only one remote peer configuration is to be set, rather than many to be added. void setRemoteConfiguration(in DOMString configuration, in optional DOMString remoteOrigin); 4. We propose swapping the ConnectionPeerConfigurationCallback callback parameters. The current example seems to use only one (the second one). Swapping them allows clients that care about 'server' to do so, and clients that ignore it (such as the current example) to do so too. [Callback=FunctionOnly, NoInterfaceObject] interface ConnectionPeerConfigurationCallback { void handleEvent(in DOMString configuration, in ConnectionPeer server); }; 5. Should a size limit to text messages be specified? Text messages with UDP-like behavior (unimportant=true) can't really be reliably split into several UDP packets. For such long chunks of data, file transfer seems like a better option anyway. In summary, then, our proposal for a revised ConnectionPeer looks as follows: [Constructor(in DOMString serverConfiguration)] interface ConnectionPeer { void sendText(in DOMString text, in optional boolean unimportant); // if second arg is true, then use unreliable low-latency transport (UDP-like), otherwise guarantee delivery (TCP-like) attribute Function ontext; // receiving void sendBitmap(in HTMLImageElement image); attribute Function onbitmap; // receiving void sendFile(in File file); attribute Function onfile; // receiving void addStream(in Stream stream, in optional DOMString metadata, in optional String mediaFormat); //Start stream, add meta data and encoding parameters void removeStream(in Stream stream); readonly attribute Stream[] localStreams; readonly attribute Stream[] remoteStreams; attribute Function onstreamadded; // receiving new stream attribute Function onstreamremoved; // stream not received any more void getLocalConfiguration(in ConnectionPeerConfigurationCallback callback); // maybe this should be in the constructor, or be an event void setRemoteConfiguration(in DOMString configuration, in optional DOMString remoteOrigin); // remote origin is assumed to be same-origin if not specified. If specified, has to match remote origin (checked in handshake). Should support leading "*." to mean "any subdomain of". void close(); // disconnects and stops listening attribute Function onconnect; attribute Function onerror; attribute Function ondisconnect; const unsigned short CONNECTING = 0; const unsigned short CONNECTED = 1; const unsigned short CLOSED = 2; readonly attribute unsigned short readyState; }; interface RemoteStreamEvent : Event { readonly attribute Stream stream; }; [Callback=FunctionOnly, NoInterfaceObject] interface ConnectionPeerConfigurationCallback { void handleEvent(in DOMString configuration, in ConnectionPeer server); }; In addition to the above there is a need to add support for identifying streams (so that the receiving end can use the right element for rendering) and for negotiating and influencing the media format. Those parts we're still looking into. But all in all we think ConnectionPeer is a very good starting point for an API. Br, Stefan -- Patrik Persson, Ericsson Research mailto:patrik.j.persson@ericsson.com

1 0