Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Cullen Jennings <fluffy@iii.ca> Sat, 20 July 2013 01:47 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CBC11E81AA for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 18:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level:
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDqqsTI9sjo5 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 18:47:37 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0630521F9FFC for <rtcweb@ietf.org>; Fri, 19 Jul 2013 18:47:36 -0700 (PDT)
Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B7C5422E1F3; Fri, 19 Jul 2013 21:47:35 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAJrXDUHBVRoYeLfGebH4R93Vv9-kAS80srPJyOPjmxawO8DC1A@mail.gmail.com>
Date: Fri, 19 Jul 2013 18:47:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7AB6A4D-D2F1-4896-8D30-771D0312A2F0@iii.ca>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <CAD5OKxtKLMf_d=8GSMrqfNhDHPe9MFP2ZTKzZHFn9CyMr-gSVQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <CAD5OKxvGfkgRp6tXwbOu_kVteHiBBqsyR5ixH18FMKjCNGO8VQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CAJrXDUHBVRoYeLfGebH4R93Vv9-kAS80srPJyOPjmxawO8DC1A@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
X-Mailer: Apple Mail (2.1508)
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 01:47:45 -0000

Well that was clearly one or my more mindless emails 

What I mean to say was something along lines of 

Folks want to sort out the multiplexing / bundle stuff first. 

So let me suggest that folks read section 6 of the JSEP draft and see if they can answer most of of the questions below. I'm not saying that section 6 is right, in fact I think some of it is wrong. But at least act like you have read it.


On Jul 19, 2013, at 7:49 AM, Peter Thatcher <pthatcher@google.com> wrote:

> "mindless works fist"?  There's a deep meaning there, but I'm still trying to figure it out...
> 
> 
> On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> Folks wanted to sort out how mindless works fist before getting to theses smaller details but in general I think progress is being made on all of these
> 
> On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> wrote:
> 
> > Bernard Aboba:
> >>
> >> The problem was that we never defined what mangling browsers had to
> >> support. Given all the SDP specs that is actually a huge work item.
> >
> >
> > This is exactly what my slides that weren't presented last November started to touch upon. It only takes a few minutes with RFC3264 and its references to start documenting cases that are clearly "valid SDP offer/answer" and yet for which I cannot for the life of me figure out what a browser should do if they're presented.
> >
> > Just off the top of my head:
> >
> > Can I...
> > - Change the t= line to be something other than t=0 0?

Current JSEP draft says the browser does not need to allow that to be changed.

> > - Change the rtpmap associations before calling setLocal?

you can remove or reorder

> > - Change a=sendrecv to a=recvonly before calling setLocal?

Current JSEP draft says that is done with constraints

> > - What do you do when you see a=content:sl ?

not in current spec but you can find dissection on list about making sure that is available to API 

> > - What if someone adds an r= or p= or e=?

Current JSEP draft says the browser does not need to allow that 

> - What is the RFC that describes a=group:BUNDLE (as seen in some browser implementations)?

Uh, I'll leave that as an exercise to the readers. Try hard and see if you can find it. 


> > - Can I remove a=group:BUNDLE (or add it) before calling setLocal?

Current JSEP draft says that is done with constraints

> > - How about removing a=rtcp-mux?

Current JSEP draft says that is done with constraints


> > - Should I do something special at my end if you set a=ice-options:google-ice ?

Do whatever the ice spec say 

> > - If you put a=ssrc lines in there, can I change the ssrc before passing it back to setLocal?
Current JSEP draft says the browser does not need to allow that to be changed.


> > - Can I delete the a=ssrc lines?

Current JSEP draft says the browser does not need to allow that to be changed.


> > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not?

Why would a browser want to generate that?

> > - What about 0.0.0.0 in the o= line?

Why would a browser want to generate that?

> > - If I get a bunch of a=candidate lines, can I swap them around to change the priority before calling setLocal?

Current JSEP draft says the browser does not need to allow that to be changed.

> > - What if someone claims SAVP instead of SAVPF but gives me rtcp info?

We need to add text to explicitly cover that. You can find text on what I think we should do for this in 
draft-jennings-rtcweb-plan-01


> >
> > At the *very least* for each and every line that comes from createOffer and createAnswer you must be able to answer the following:
> > - Can I delete it?
> > - Duplicate it?
> > - Change it?
> > - If not, how are violation handled? (Both when passed to another browser at the far end and when these modifications happen before calling setLocal)
> > - And can I add additional valid SDP to what came from createOffer or createAnswer and pass it back to setLocal or not?
> >
> > We appear to be nowhere near a document which explains the answers to these questions, certainly not in the W3C WG, and not in any IETF RFC or draft I can locate.

draft-ietf-rtcweb-jsep-03 has tried to address some of these. I certainly don't claim it is perfect but if people have use cases that suggest a change to this, love to get text on what it should be. 

Mathew has been very clear along the way of "we need to define X to have an interoperable system" and for most values of X he has proposed, I agree with him. However, I think we just need to do that and that it actually won't be much work once we get the framework in place to deal with thinks like how many ports is the RTP using and how many m-lines does the SDP have. 

> >
> > Matthew Kaufman
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>