February 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

WG charter, take 4
by Harald Alvestrand 04 Mar '11

04 Mar '11

This is the current charter text - it's updated somewhat based on discussions on the list. In particular, there's now suggested language about the relationship to session management protocols. We'll make this an explicit discussion at the BOF, with the aim of getting one of three conclusions in the charter: - The WG will not address session management protocols - The WG will choose one or more session management protocols - The WG will discuss session management protocols, and do what makes sense. The last one is the one suggested by the current charter text; the other possible outcomes should be easier to write text for. Comments welcome! Harald (Note: The below is not going out in < 80 columns, I think. Please forgive the formatting issue.) ------------------------------------------------ Version: 4 Name: RTCWEB WG Chair(s): Cullen Jennings <fluffy(a)cisco.com> 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 described 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. This group's primary aim is to enable web applications to manage real-time communication sessions with other web-context applications that implement this specification. When making choices, the working group will also consider the impact of those choices on interoperability with other devices that create or manage multimedia sessions, including the complexity imposed on any gateways which may be required. The Working group will identify information needed for session negotiation and management in web contexts, and its output documents will describe the relationship of this to information carried in session protocols used in other standardized contexts. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. 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 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, and if there are parts of the mapping between the API and the protocols that need to be done outside of the W3C, this group will do it. 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. Deliverables: An overview document describing the architecture A scenarios document describing scenarios that are expected to be supported A profile document specifying the protocols and options that must be supported by a conforming implementation (If needed) A mapping document describing the relationship between the protocols and the W3C-defined API. 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 Draft available of 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 document submitted to the IESG as Informational (if needed)

11 23

Re: [RTW] WG charter, take 4
by Elwell, John 25 Feb '11

25 Feb '11

+1 John > -----Original Message----- > From: rtc-web-bounces(a)alvestrand.no > [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of > Rosenberg, Jonathan > Sent: 24 February 2011 16:33 > To: 'Harald Alvestrand'; RTC-Web(a)alvestrand.no > Subject: Re: [RTW] WG charter, take 4 > > A few comments: > > I'm happy with the charter language around discussion of session > management protocols being in scope for the WG. I don't > understand why, > during the BoF, we will discuss whether to bake a decision on > this into > the charter. Determining the protocols needed for browser RTC > - both the > types of protocols and specific protocol instances and > profiles - is the > work of the group and NOT the work of the charter. > > This piece of wording is also concerning: > >have interactive real time voice and video pairwise between > browsers or > >other devices using RTP > > While I think we agree this is a goal, there are real > security issues in > play here that the group needs to iron out. I do not want to bake in a > charter requirement that says we MUST deliver a solution that allows > point-to-point media (i.e., no gateways or SBCs or other > intermediaries) > between browsers and existing RTP endpoints. I'd suggest > something softer > like: > > "enable real-time voice and video communications between browsers and > non-browser endpoints, with direct media when possible based > on security > and interoperability considerations" > > Which states the intent but leaves the recommendation to the wg. > > Thanks, > Jonathan R. > > > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > Skype Chief Technology Strategist > jdrosen(a)skype.net http://www.skype.com > jdrosen(a)jdrosen.net http://www.jdrosen.net > > > -----Original Message----- > From: rtc-web-bounces(a)alvestrand.no > [mailto:rtc-web-bounces@alvestrand.no] > On Behalf Of Harald Alvestrand > Sent: Thursday, February 24, 2011 8:45 AM > To: RTC-Web(a)alvestrand.no > Subject: [RTW] WG charter, take 4 > > This is the current charter text - it's updated somewhat based on > discussions on the list. > > In particular, there's now suggested language about the > relationship to > session management protocols. > We'll make this an explicit discussion at the BOF, with the aim of > getting one of three conclusions in the charter: > > - The WG will not address session management protocols > - The WG will choose one or more session management protocols > - The WG will discuss session management protocols, and do what makes > sense. > > The last one is the one suggested by the current charter > text; the other > possible outcomes should be easier to write text for. > > Comments welcome! > > Harald > > (Note: The below is not going out in < 80 columns, I think. Please > forgive the formatting issue.) > > ------------------------------------------------ > > Version: 4 > > Name: RTCWEB > WG Chair(s): Cullen Jennings <fluffy(a)cisco.com> > > 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 described 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. > > This group's primary aim is to enable web applications to manage > real-time communication sessions with other web-context applications > that implement this specification. When making choices, the working > group will also consider the impact of those choices on > interoperability > with other devices that create or manage multimedia sessions, > including > the complexity imposed > on any gateways which may be required. > > The Working group will identify information needed for session > negotiation and management in web contexts, and its output documents > will describe the relationship of this to information carried > in session > protocols used in other standardized contexts. > > The Working Group will consider the possibility of defining a browser > component that implements an existing session negotiation and > management > protocol. > > 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 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, and if > there are parts of the mapping between the API and the protocols that > need to be done outside of the W3C, this group will do it. > > 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. > > Deliverables: > An overview document describing the architecture > A scenarios document describing scenarios that are expected to be > supported > A profile document specifying the protocols and options that must be > supported by a conforming implementation > (If needed) A mapping document describing the relationship between the > protocols and the W3C-defined API. > > > 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 Draft available of 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 document submitted to the IESG as Informational (if > needed) > > > _______________________________________________ > 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 >

2 1

Re: [RTW] WG charter, take 4
by Bernard Aboba 25 Feb '11

25 Feb '11

Agree with Jonathan on the security issues below. Personally, I'd like to see an analysis of the issues added to the charter -- along with some opportunity for the security community to review the document. Allowing P2P media is a non-trivial change to the security threat model of the browser. -----Original Message----- From: rtc-web-bounces(a)alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Rosenberg, Jonathan Sent: Thursday, February 24, 2011 8:33 AM To: 'Harald Alvestrand'; RTC-Web(a)alvestrand.no Subject: Re: [RTW] WG charter, take 4 A few comments: I'm happy with the charter language around discussion of session management protocols being in scope for the WG. I don't understand why, during the BoF, we will discuss whether to bake a decision on this into the charter. Determining the protocols needed for browser RTC - both the types of protocols and specific protocol instances and profiles - is the work of the group and NOT the work of the charter. This piece of wording is also concerning: >have interactive real time voice and video pairwise between browsers or >other devices using RTP While I think we agree this is a goal, there are real security issues in play here that the group needs to iron out. I do not want to bake in a charter requirement that says we MUST deliver a solution that allows point-to-point media (i.e., no gateways or SBCs or other intermediaries) between browsers and existing RTP endpoints. I'd suggest something softer like: "enable real-time voice and video communications between browsers and non-browser endpoints, with direct media when possible based on security and interoperability considerations" Which states the intent but leaves the recommendation to the wg. Thanks, Jonathan R. Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Skype Chief Technology Strategist jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net -----Original Message----- From: rtc-web-bounces(a)alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand Sent: Thursday, February 24, 2011 8:45 AM To: RTC-Web(a)alvestrand.no Subject: [RTW] WG charter, take 4 This is the current charter text - it's updated somewhat based on discussions on the list. In particular, there's now suggested language about the relationship to session management protocols. We'll make this an explicit discussion at the BOF, with the aim of getting one of three conclusions in the charter: - The WG will not address session management protocols - The WG will choose one or more session management protocols - The WG will discuss session management protocols, and do what makes sense. The last one is the one suggested by the current charter text; the other possible outcomes should be easier to write text for. Comments welcome! Harald (Note: The below is not going out in < 80 columns, I think. Please forgive the formatting issue.) ------------------------------------------------ Version: 4 Name: RTCWEB WG Chair(s): Cullen Jennings <fluffy(a)cisco.com> 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 described 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. This group's primary aim is to enable web applications to manage real-time communication sessions with other web-context applications that implement this specification. When making choices, the working group will also consider the impact of those choices on interoperability with other devices that create or manage multimedia sessions, including the complexity imposed on any gateways which may be required. The Working group will identify information needed for session negotiation and management in web contexts, and its output documents will describe the relationship of this to information carried in session protocols used in other standardized contexts. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. 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 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, and if there are parts of the mapping between the API and the protocols that need to be done outside of the W3C, this group will do it. 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. Deliverables: An overview document describing the architecture A scenarios document describing scenarios that are expected to be supported A profile document specifying the protocols and options that must be supported by a conforming implementation (If needed) A mapping document describing the relationship between the protocols and the W3C-defined API. 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 Draft available of 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 document submitted to the IESG as Informational (if needed) _______________________________________________ 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

2 3

Re: [RTW] [dispatch] RTCWEB I-D with thoughts on the framework
by Stefan Håkansson LK 23 Feb '11

23 Feb '11

I agree to large parts of the document, and I think that the section on interoperability with existing VoIP gear brings up important aspects. However, I am not completely comfortable with a couple of things: * The application would be responsible for rate adaptation, but what is the incentive for the application developer to do something that is fair to other applications or users? I would prefer that this is part of the browser (and with the auto update feature most browsers use the update cycles could be short anyway) * Are you suggesting that the <video> (and consequently also the <audio>) tag should not be used? I don't think this is a good idea. Since they are accepted and used by the web community we should use them also for RTC-Web rather than trying to invent something new. --Stefan > -----Original Message----- > From: dispatch-bounces(a)ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: den 8 februari 2011 15:49 > To: 'DISPATCH list' > Subject: [dispatch] RTCWEB I-D with thoughts on the framework > > Some of my colleagues from Skype and I have put together a > draft which gives our thoughts on the scope of the protocols > and functionality for enabling browser RTC. I've just > submitted the draft, which you can find > here: > > http://www.ietf.org/id/draft-rosenberg-rtcweb-framework-00.txt > > Some of the key points: > > * keep it minimal > * APIs for controlling behaviors of the various media > components, with defaults for those that dont care > * no SIP or Jingle; leave that to proprietary over websockets/HTTP > * no ICE - just STUN. ICE can be a javascript library. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > Skype Chief Technology Strategist > 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 >

3 4

MOCSP
by SHANMUGALINGAM SIVASOTHY 22 Feb '11

22 Feb '11

>>> Hi! >>> >>> I published a paper for enabling innovation by giving more control to >>> users. >>> >>> I hope I may add some requirements to RTC-Web. >>> >>> Shanmugalingam, S.; Crespi, N.; Labrogere, P.; , "My Own Communication >>> Service Provider," Ultra Modern Telecommunications and Control Systems and >>> Workshops (ICUMT), 2010 International Congress on , vol., no., pp.260-266, >>> 18-20 Oct. 2010 >>> >>> >>> Pls give your comments. Also I am IETF fellow for next meeting (IETF 80). >>> Hope to see you all. >>> >>> Best regards >>> Siva >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0

Name of group: RTCWEB or voting?
by Harald Alvestrand 19 Feb '11

19 Feb '11

It seems that most people have been comfortable with referring to this effort as RTCWEB. That's also the name we got our BOF approved under. Our current charter draft at http://rtc-web.alvestrand.com/ietf-activity has a kitchen-sink list of possible names; we could in theory hold a straw poll on the list, ask everyone to rank their preferred opinion, do a Condorcet-method ranking exercise on the result, and hope that we don't end up with a preference loop... but it might be simpler to just declare consensus and leave it as-is. If Ted, Cullen and I don't hear a groundswell of opinion that we need to run a straw poll exercise, we'll just leave it as RTCWEB, and remove the alternatives. Seems OK? Harald

8 7

Criteria for what one can do in Javascript vs what one has to do inside the browser
by Harald Alvestrand 18 Feb '11

18 Feb '11

Trying to sort out thoughts in my own head.... I've run a few experiments, and thought a few thoughts. There are a couple of things that should NOT be permitted from Javascript in an RTC-Web enabled application, and there are a couple of things that just can't be done at the present stage of our codebase. Things that should not be permitted: - Sending an UDP packet with script-specified content to a script-specified destination. This has far too much potential for havoc (imagine them being fired at business critical systems, DNS servers or SNMP monitoring ports). - Setting up a TCP connection to a script-specified destination and sending script-specified data down it. Same issues as above. The traditional defense against the second type is the "same origin policy", policed by browsers in their implementation of XmlHttpGet, WebSockets and similar interfaces, which also limits requests to more-or-less valid HTTP (but see http://www.alvestrand.no/ietf/http-traps.html for some fun abuses that used to work...) So far, we have assumed that the STUN handshake is our defense against the first one, and that it's OK to send out a moderate amount of STUN-formatted UDP packets to ports and IP addresses chosen by the script, believing that the STUN format prevents them from being parsed as valid packets by other protocols. (Query: What other operations need to be protected against?) Things that can't be done: - Anything that requires timing of events within 20-100 ms of each other - Anything that depends on multithreading behaviour in the browser In both cases, Javascript just doesn't work that way. I think the TCP constraint + the UDP constraint means that we can't implement SIP or XMPP in Javascript without a gateway that talks SIP-over-HTTP - you just can't get around the security features. I think the timing constraint means that if you implement ICE in Javascript, you're going to need to have seriously relaxed timing constraints - the standard specifies that you should try candidates at <complicated expression that usually turns out to be 20 ms>. What else are serious limitations on what we can or cannot do? What are the consequences? Harald

5 8

Re: [RTW] Fwd: Second screen, low-delay control channels (Re: BOF agenda uploaded to IETF servers)
by Matt Hammond 17 Feb '11

17 Feb '11

Hi, Dan mentioned that he had posted here regarding second screen and remote controls, so I thought I should chip in. As he mentioned, I was also at the W3C Web and TV workshop and presented some work we have been doing at the BBC in this area. >> On 15 February 2011 15:10, Harald Alvestrand<harald(a)alvestrand.no> >> wrote: > > I'm not sure - to me it seems like second-screen applications need 2 > types of data: > - Media data from a server, which are pretty well served by current > streaming-over-HTTP efforts > - Control data that go between the devices, which frequently could > benefit from a direct link to keep latency down. > > In this use case, we could easily imagine using the RTC-web channel > establishment functionality, but not pass media over them. This could > be appropriate/important for some home situations, such as "TV on > fixed network, remote on WLAN network, phone on 3G". I am thinking of control, not streaming of media. The approach we've worked on is to enable high level control of a TV's functions from a "second screen"/"remote control" client device. The kinds of functions to be controlled would include: changing volume, querying what programme/channel is currently playing, changing channel, booking recordings, playing recordings, etc. Clients could be browser based, or phone/tablet/PC applications or dedicated single purpose/embedded devices. An interesting example might be an 'accessible' remote control for a user with motor impairments. The first interest for me is in establishing a direct channel between devices in the home LAN - hence in our experiments we put an HTTP server on the TV. However, I agree with Dan that there are many very interesting possibilities that present themselves if that channel can bridge outside of that domain. If you think this could fit into the group's remit, then we would try to bring some less hazy use cases to the table to help with the scoping. regards Matt > What do others think? Should we add such a scenario to our (so far > virtual) list of scenarios? >> >> Last week I attended W3C's "TV and Web" Workshop in Berlin. >> http://www.w3.org/2010/11/web-and-tv/ >> There's a workshop report in preparation but the raw materials are >> linked from >> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Feb/0007.html >> >> There were a number of presentations (including mine) on theme of >> using devices (smart phones, tablets) as "second screens", for remote >> control functionality, but also to provide additional information, >> interactivity, social functionality etc to accompany TVs and related >> media centre devices. I showed some work that used XMPP to provide >> such a communications channel, and Matt Hammond from the BBC showed >> their HTTP/REST-based efforts. In both cases, "second screen" >> scenarios have some familiar difficulties, and the RTC work was >> discussed as a potential effort that could address these problems. >> >> When using classic server-mediated XMPP, remote control apps suffer >> from latency. XMPP allows us to address devices logically, but its >> point-to-point use in LAN-local scenarios, or when the devices are on >> different networks, is relatively immature (although JINGLE and >> XEP-0174 show it growing in that direction). >> >> When devices expose TV services over HTTP (as in the BBC work) things >> are relatively simple so long as both devices are on the same LAN, but >> otherwise there are difficulties. >> >> There is interest in the W3C TV Interest Group community towards >> standardising something in support of "second screen" remote control >> TV / media centre scenarios. But also a healthy concern to avoid >> re-inventing wheels - hence this message. >> >> My small understanding of RTC is that you will be addressing nat >> traversal issues, and will likely have some kind of control channel >> for direct (non-server mediated) signalling between endpoints. I would >> be grateful for any help in understanding whether these pieces >> could/should/might be relevant to any hypothetical new "TV-style >> remotes" W3C work as sketched above. >> >> Thanks for any advice, and sorry that the requirement/scenario is >> sketchy, some of us are working to come up with a more detailed >> picture asap, >> >> cheers, >> >> Dan >> > > _______________________________________________ > RTC-Web mailing list > RTC-Web(a)alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/

1 0

BOF agenda uploaded to IETF servers
by Harald Alvestrand 16 Feb '11

16 Feb '11

I've uploaded our preliminary draft BOF agenda to the IETF server: http://www.ietf.org/proceedings/80/agenda/rtcweb.txt Comments welcome! Harald

6 8