February 2011 - RTC-Web

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

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

09 Feb '11

Also work or just work? Слава ----- Reply message ----- От: "Xavier Marjou" <xavier.marjou(a)gmail.com> Дата: ср, фев 9, 2011 22:26 Тема: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP Кому: "Henry Sinnreich" <henry.sinnreich(a)gmail.com> Копия: "rtc-web(a)alvestrand.no" <rtc-web(a)alvestrand.no>, "DISPATCH list" <dispatch(a)ietf.org> Hi, Hi Henry, These requirements certainly do not want to cripple innovation (RTC-Web). They rather want to catch attention so that RTC-Web is designed in a way it can also work with existing SIP-RTP devices. Cheers, Xavier On Wed, Feb 9, 2011 at 6:36 PM, Henry Sinnreich <henry.sinnreich(a)gmail.com<mailto:henry.sinnreich@gmail.com>> wrote: GENERIC-REQ-1 The [RTC-Web] solution MUST be designed in a such way it allows interworking with SIP-RTP applications both at the signalling and media level. Please help me understand how this and the other requirements do not cripple the whole concept of the RTC-Web (innovation based on simplicity and flexibility) by making it just another extension of legacy telecom design? Or did the authors mean requirements for gateways only? Thanks, Henry On 2/9/11 3:06 AM, "Xavier Marjou" <xavier.marjou(a)orange-ftgroup.com<http://xavier.marjou@orange-ftgroup.com>> wrote: 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 ________________________________ _______________________________________________ dispatch mailing list dispatch(a)ietf.org<http://dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ RTC-Web mailing list RTC-Web(a)alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web

1 0

Agenda proposal, RTCWEB BOF in Prague
by Harald Alvestrand 04 Feb '11

04 Feb '11

Ted Hardie and I put this together. Please comment! Name: RTCWEB - Real Time Communication on the World Wide Web BOF Chairs: Harald Alvestrand, Ted Hardie Expected # of attendees: 150 Length of session: 2.5 hours Conflicts to avoid: RAI area, DISPATCH, CODEC, HYBI Webex NOT required. Description: A proposal for a new working group in the RAI area is presently before the RAI area chairs. The charter proposal is here: <URL coming> This BOF will give an overview of the problem space and possible action items, discuss the technology that is being proposed, and describe the relationship with other work efforts inside and outside the IETF. Relevant mailing list: rtcweb(a)alvestrand.no <mailto:rtcweb@alvestrand.no>- www.alvestrand.no/mailman/listinfo/rtcweb <http://www.alvestrand.no/mailman/listinfo/rtcweb>to subscribe. Drafts: draft-alvestrand-dispatch-rtcweb-datagram draft-alvestrand-dispatch-rtcweb-protocols <this list will grow> Agenda: 00:00 Agenda bashing, blue sheet, scribe selection, note well 00:05 Brief introduction of the problem space and scope limitations 00:10 Overview of proposed action items for the WG, should it be chartered (also give forward reference to W3C coordination description to come). 00:20 Technology Discussion 00:20 Overall model of RTW in the Web - draft: rtcweb-protocols 00:30 Requirements/scenarios work - Describe how to gather, document and triage requirements 00:55 Profiling STUN for RTCWeb - draft: rtcweb-datagrams 01:10 Negotiation mechanisms 01:25 Criteria for work done in the browser Keywords: Security models, DDoS, execution speed, resource access 01:40 Scope and methods of W3C API work - see posted W3C charter proposal 01:50 Criteria for mandatory to implement codecs, syntax <name?> 02:05 Call for volunteers for specific work items 02:20 Charter hum

1 0

Fwd: [dispatch] RTCWEB BOF was (Re: Summary: topics put forth for IETF-80)
by Harald Alvestrand 04 Feb '11

04 Feb '11

We have our approval for a BOF in Prague. -------- Original Message -------- Subject: [dispatch] RTCWEB BOF was (Re: Summary: topics put forth for IETF-80) Date: Wed, 2 Feb 2011 10:24:48 +0200 From: Gonzalo Camarillo <Gonzalo.Camarillo(a)ericsson.com> To: Mary Barnes <mary.ietf.barnes(a)gmail.com> CC: DISPATCH <dispatch(a)ietf.org>, "rai-ads(a)tools.ietf.org" <rai-ads(a)tools.ietf.org> Folks, > 1) RTCWEB: > http://www.ietf.org/mail-archive/web/dispatch/current/msg03171.html > > Excellent feedback and discussion thus far. An official Bof has been > approved for this topic: > http://trac.tools.ietf.org/bof/trac/#RAI Yes, we will have an RTCWEB BOF in Prague. The goal is to try and form a new WG. As you all know, the process of chartering a WG is a scoping process aimed to define what is in and what is out of the scope of the WG. Given that RTCWEB is a large area, there may be topics that come up during the discussions that do not end up in the charter of the WG for some reason. If that was the case, we would decide what to do with them in DISPATCH afterward. Right now, our focus should be to work on a good charter proposal. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch

1 0

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