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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Wed, 17 July 2013 21:59 UTC

Return-Path: <matthew.kaufman@skype.net>
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 DB41D21F9DFA for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 14:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.761
X-Spam-Level:
X-Spam-Status: No, score=-3.761 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 5bsdz+rSFQ32 for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 14:59:44 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5088221F9E26 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 14:59:44 -0700 (PDT)
Received: from mail86-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 21:59:43 +0000
Received: from mail86-co9 (localhost [127.0.0.1]) by mail86-co9-R.bigfish.com (Postfix) with ESMTP id 94B304E0077; Wed, 17 Jul 2013 21:59:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: -1
X-BigFish: VS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail86-co9: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail86-co9 (localhost.localdomain [127.0.0.1]) by mail86-co9 (MessageSwitch) id 1374098381101368_23104; Wed, 17 Jul 2013 21:59:41 +0000 (UTC)
Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.248]) by mail86-co9.bigfish.com (Postfix) with ESMTP id 146E24C0049; Wed, 17 Jul 2013 21:59:41 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 21:59:35 +0000
Received: from TK5EX14MBXC265.redmond.corp.microsoft.com ([169.254.3.88]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Wed, 17 Jul 2013 21:58:37 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
Thread-Index: AQHOgoLR5V+chGbsUEageQv6sS/XzplpaE4A
Date: Wed, 17 Jul 2013 21:58:37 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com>
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>
In-Reply-To: <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: skype.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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: Wed, 17 Jul 2013 21:59:53 -0000

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?
- Change the rtpmap associations before calling setLocal?
- Change a=sendrecv to a=recvonly before calling setLocal?
- What do you do when you see a=content:sl ?
- What if someone adds an r= or p= or e=?
- What is the RFC that describes a=group:BUNDLE (as seen in some browser implementations)?
- Can I remove a=group:BUNDLE (or add it) before calling setLocal?
- How about removing a=rtcp-mux?
- Should I do something special at my end if you set a=ice-options:google-ice ?
- If you put a=ssrc lines in there, can I change the ssrc before passing it back to setLocal?
- Can I delete the a=ssrc lines?
- Is a=rtcp:1 IN IP4 0.0.0.0 valid or not?
- What about 0.0.0.0 in the o= line?
- If I get a bunch of a=candidate lines, can I swap them around to change the priority before calling setLocal?
- What if someone claims SAVP instead of SAVPF but gives me rtcp info?
	
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.

Matthew Kaufman