- RTC-Web - alvestrand.no

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

New version: draft-alvestrand-dispatch-rtcweb-datagram-01
by Harald Alvestrand 15 Feb '11

15 Feb '11

I updated this draft with some of the comments from the mailing list, and some other revisions and clarifications. Input for discussions. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-datagram-01 Date: Tue, 15 Feb 2011 03:58:38 -0800 (PST) From: IETF I-D Submission Tool <idsubmission(a)ietf.org> To: harald(a)alvestrand.no A new version of I-D, draft-alvestrand-dispatch-rtcweb-datagram-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-dispatch-rtcweb-datagram Revision: 01 Title: A Datagram Transport for the RTC-Web profile Creation_date: 2011-02-15 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document describes a combination and profiling of existing IETF protocols to provide a datagram service that is suitable as a generic transport substrate for the RTC-Web family of real-time audio/video applications. The IETF Secretariat.

1 0

Axles we don't have to wrap ourselves around
by Ted Hardie 10 Feb '11

10 Feb '11

So, I just finished reading draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt, draft-rosenberg-rtcweb-framework-00.txt, and the thread to date. Both drafts have some nice ascii art showing where they expect specific pieces of functionality to sit. The Marjou et al draft has this: ----------------- ----------------- | RTC-Web | | SIP-RTP | | application | | application | |-----------------| | | |rtcweb rtcweb | | | | sig media | | | | APIs APIs | | | |-----------------| | | | | | | | ----- | | ----- | || SIP | |<-----------SIP----------->|| SIP | | ||stack| | ||stack| | | ----- | | ----- | | ----- | | ----- | | | RTP ||<-----------RTP----------->| | RTP || | |stack|| | |stack|| | ----- | | ----- | ----------------- ----------------- and the Rosenberg et al draft has this: +------------------------+ On-the-wire | | Protocols | Servers |---------> | | | | +------------------------+ ^ | | | HTTP/ | Websockets | | | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^RTC APIs | |APIs +---|-----------------|------+ | | | | | +---------+| | | Browser || On-the-wire | Browser | RTC || Protocols | | Function|-----------> | | || | | || | +---------+| +---------------------|------+ | V Native OS Services I have to say that I like the term "RTC-Web application" better. The working group appears to me to be taking on specifying how to use a set of web technologies to talk to a web-based rendezvous server (and potential intermediary) for real-time communications. That may be because they want to have live video of their poker partners on a gaming site, because they want their shared desktop/conferencing software to be able to call out to participants, or for any one of a number of other scenarios. But the fact that it is a *browser* who acts as a client should not be our focus. If an app on a mobile platform wants to use the same technologies, for example, that should be fine with us even if it is not a "browser". I think that means we don't need to be quite so wrapped around the axle as to which hunk of code holds which functionality. We need to be clear which pieces of functionality we'll provide, but we should assume that continuing evolution may mean that some bit will move from app/browser to OS just as they are now moving from plugin to core application capability. Just two cents with no hats on, Ted

3 4

НА: [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP
by Slava Borilin 09 Feb '11

09 Feb '11

Dear all, Let me throw in another question- when all of us are talking media, we think its audio-video only. But in practice, real-time data such as vnc, is also now part of real-time media session, and it must follow the same Nat-traversal scenario, as audio & video, but not necessarily the rtp protocol (but TCP). I think if we put stun in browser, it should be available not only for rtp sessions. Based on videoconferencing experience. Слава ----- Reply message ----- От: "Markus.Isomaki(a)nokia.com" <Markus.Isomaki(a)nokia.com> Дата: ср, фев 9, 2011 22:53 Тема: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Кому: "xavier.marjou(a)orange-ftgroup.com" <xavier.marjou(a)orange-ftgroup.com>, "dispatch(a)ietf.org" <dispatch(a)ietf.org> Копия: "rtc-web(a)alvestrand.no" <rtc-web(a)alvestrand.no> Hi Xavier and Jean-Francois, Thanks for putting this together. Based on the recent list discussion, I would say that quite many people are leaning towards the architecture you depict in Section 5.2, Figure 2: The session setup protocol is an application specific Javascript implementation transported over HTTP or WebSocket, while media is running on standard RTP supported by the browser. In that model we can’t put many requirements on the session setup protocol or its interworking with SIP. If the service provider needs SIP interoperability (to connect to PSTN, to other service providers or SIP phones), it is indeed THEIR burden to make sure they use something that has a clean mapping to SIP – for instance, that they can do things like call hold. On the other hand if the service provider is not interested in SIP interoperability, they do not have to worry about that. In the IETF there are probably two ways to address this interworking: a) do nothing and leave it completely to the implementers and service providers, or b) define some kind of a SIP/BOSH/HTTP or SIP/WebSocket mapping in the same way that the XMPP folks have done. The XMPP/BOSH spec does have implementations both on the client/Javascript side as well as on the server side, so I think that spec has had some value. (At least in a way that the Javascript library and the BOSH servers can be implemented somewhat independently.) The RTP/media stack on the other hand is definitely in the scope of the IETF effort. I think we should standardize the RTP use in the browsers and that would be one step towards interop with SIP phones. The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC). DTMF transport capability may also be relevant interop requirement. I think these are the key issues we should consider wrt. SIP phone interop. Markus From: rtc-web-bounces(a)alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Xavier Marjou Sent: 09 February, 2011 11:07 To: DISPATCH list Cc: rtc-web(a)alvestrand.no; Jean-François Jestin Subject: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Hi, We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-in… Cheers, Xavier and Jean-François

2 1

Re: [RTW] [dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP
by Markus.Isomaki＠nokia.com 09 Feb '11

09 Feb '11

Hi Peter, I hope I'm answering the right question: I think something like the STUN connectivity check or authorization is required to be implemented in the browser to prevent the Javascript application from sending RTP or some other UDP data to any arbitrary IP addresses and port. If the browser only allows the sending after a successful connectivity check it can ensure (to some extent) that the other peer also actually wants to receive this traffic. That code needs to reside in the browser so that the browser can act as the gatekeeper. Markus From: ext Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: 09 February, 2011 22:16 To: Adam Roach Cc: Isomaki Markus (Nokia-CIC/Espoo); rtc-web(a)alvestrand.no; dispatch(a)ietf.org; xavier.marjou(a)orange-ftgroup.com Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP I also agree with the "make RTP just work" - signal where and how you want.. Sorry if I am being dense here - do we not need ICE connectivity checks to finish before RTP can be sent? Or is the point that this will take too long to get into browser code and that ICE in Javascript with STUN in the browser gets rolled out faster? Peter Musgrave On 2011-02-09, at 3:07 PM, Adam Roach wrote: The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC)

1 0

[dispatch] RTC-Web I-D about interworking between RTC-Web and SIP-RTP
by Xavier Marjou 09 Feb '11

09 Feb '11

Hi, We have posted a draft about interworking requirements between RTC-Web and SIP-RTP. http://www.ietf.org/internet-drafts/draft-marjou-dispatch-rtcweb-sip-rtp-in… Cheers, Xavier and Jean-François

7 6