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

Stefan Håkansson LK <> Mon, 08 July 2013 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D22B121F9DAD for <>; Mon, 8 Jul 2013 13:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.241
X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKElcbLppn8X for <>; Mon, 8 Jul 2013 13:34:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F10EE21F9D7C for <>; Mon, 8 Jul 2013 13:34:09 -0700 (PDT)
X-AuditID: c1b4fb25-b7f826d000001766-d2-51db22407782
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DB.6C.05990.0422BD15; Mon, 8 Jul 2013 22:34:08 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 22:34:07 +0200
From: Stefan Håkansson LK <>
To: Peter Thatcher <>
Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg==
Date: Mon, 08 Jul 2013 20:34:06 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvra6D0u1Ag8apchbXlr9mtZhxYSqz xdp/7ewOzB4LNpV6LFnyk8nj1pSCAOYoLpuU1JzMstQifbsErowre7azFfyyqfjZ2MncwHhR r4uRk0NCwETi6tXrjBC2mMSFe+vZuhi5OIQEDjNK/Nq8kAnCWcgocfrfOWaQKjaBQImt+xaw gdgiApoSkyc3s3YxcnAwC/hIzN2sCBIWFqiSWH74GDtIWESgWmJJfzlEtZ5E18WtLCBhFgEV iQObE0DCvAK+EvveLWABsYUEdrNI7P2rD2IzAp3z/dQaJhCbWUBc4taT+UwQZwpILNlznhnC FpV4+fgfK4StJPFjwyUWiHo9iRtTp7BB2NoSyxa+ZobYJShxcuYTlgmMorOQjJ2FpGUWkpZZ SFoWMLKsYmTPTczMSS832sQIjIuDW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgNV6p7H/8RMCfu8tObHNl3S6b4X1hRohIaJ9ht1dtwz3iHoSWPaN86 94cPtkn88pLc9WfejpK7S9lLZjEmlXw6M+3o1mtqLyUvRhftSz6soHW+dsarM4HcN/7G1kss 9vAScDNff62jxLHw2rv6+QLydVbM+4wZd6tMEVvP/TXJe937JzZ6IclKLMUZiYZazEXFiQC1 GOmoWQIAAA==
Cc: "<>" <>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2013 20:34:15 -0000

On 7/8/13 4:38 PM, Peter Thatcher wrote:
> On Mon, Jul 8, 2013 at 5:11 AM, Stefan Håkansson LK
> <
> <>> wrote:
>     On 7/7/13 11:14 PM, Roman Shpount wrote:
>      >
>      > On Sat, Jul 6, 2013 at 2:33 AM, Stefan Håkansson LK
>      > <
>     <>
>      > <
>     <>>> wrote:
>      >
>      >     On 7/3/13 11:37 PM, Eric Rescorla wrote:
>      >      >     I'm glad to be wrong here.  Is the phrase "you
>     shouldn't have to
>      >      >     modify the SDP but rather there should be API points
>     to cover
>      >     most
>      >      >     of the use cases"  the consensus of the working group?
>      >      >
>      >      >
>      >      > I thought it was, but I'm not the chair, so maybe you
>     could ask
>      >     Harald or
>      >      > Stefan.
>      >
>      >     I definitely think this is the consensus of the working group.
>      >
>      >
>      > Can you point out when exactly this consensus was reached? This
>     is news
>      > to me, but I definitely could have missed something.
>     No I can't really. To be clear, no consensus call (or similar) has been
>     held. But every time this is discussed, what I hear is people agreeing
>     and no objections.  It was discussed a bit, e.g., at the f2f at TPAC
>     last
>     year, if you read the minutes [1] you will find some traces of that
>     discussion.
> No objections at all?  That is rather surprising to me.  I asked for
> some feedback the API in the spreadsheet from web developers, at there
> many objections from them about this part of the API.  A majority did
> say it was good enough for simple use cases, but he objections were
> still clearly non-zero.

I think we're discussing different things. I'm referring to adding API 
methods that would allow meeting most use-cases without SDP mangling - 
under the presumption that SDP O/A would be used as part of the design. 
And that is what we have been assuming, and the WebRTC WG confirmed this 
last year when it was up for discussion.

What I see being most discussed now is the role of SDP O/A - not that it 
would not be helpful to have API methods that allowed meeting use-cases 
without SDP mangling if SDP O/A stays.

> I think perhaps the web developers are not well represented at TPAC.
>   But I could be wrong.  Perhaps they are but changed their mind.  Or
> maybe they're objecting on the IETF mailing list when they should object
> on the IETF mailing list.   Or maybe the spreadsheet has a sample bias,
> while TPAC is the true sample.   I don't know, but it seems like
> something is going on, and I'd like to know what it is.
> Stefan, what do you think?  What could explain the apparent
> contradiction between objections on the mailing list vs. no objections f2f?

Again, I think that we are to some extent discussing different things 
(see above).

But I can only speculate. There is not a 100% overlap between people who 
have raised concerns on the rtcweb list and the people usually active in 
the W3C WebRTC WG, this can be a reason.

> Also, on discussions about the API, should those who want to propose
> additions (such as the NoPlan JS API I proposed) and other comments put
> them on the W3C mailing list instead of the IETF one?  Is everyone
> barking up the wrong tree?

I think API proposals should be taken to the W3C list.

> Thanks in advance for your input.
>     And, I don't understand why there would be a debate about this. There
>     are obviously many who want to define APIs (or constraints) that allow
>     most use-cases to be met without having to modify the SDP.  Why would
>     anyone have anything against that?
> I think your question actually has two questions:
> 1.  Is anyone against making additions to the API to avoid SDP munging?
> 2.  Why are they against additions to the API to avoid SDP munging?
> My personal experience for #1 is that there are some notable people in
> the WG who are very much against making additions to the API to avoid
> SDP munging.  Some of them are rather upset with me for proposing a few
> minor additions to the API (the NoPlan JS API) precisely because it
> allows the JS to go around the SDP in many cases, and they don't like
> that.  So, from my experience, it's clear that the answer to #1 is "yes,
> many do".

Just to be clear, what I meant in my comment was APIs that made the 
browser create an SDP that is suitable for the use-case at hand, not an 
API to go around SDP.

> And since many object to such additions, and others want such additions,
> you end up with debate.
> How about #2?  Why do they object?  My experience is that they view any
> additions as a threat to API as a threat to the current API, which means
> it's a threat to the current WG progress, which means it's a threat to
> getting done.  They are very sensitive to such threats, and so object to
> any additions or changes that would allow JS to avoid using SDP.

I must admit I am personally also a bit afraid of WG progress if we 
change too much. If your proposed API addition would be "too much" is 
another question.

> Also,
> I think they don't want to ways of doing things, so SDP must remain the
> one true way.
> But that's just my personal experience and perspective.  I could just be
> seeing it wrong, or maybe the only person experiencing this.
>     I If there is anyone who really wants
>     to modify the SDP instead (I have no clue why, but anyway) they can
>     still do that.
> Well, no one is going to hit themselves in the head with a hammer if
> they don't have to, but there are many uses cases that currently be done
> only by SDP munging, and I don't see any API additions on the horizon
> that will help those uses cases.    So, until we can agree on some API
> additions that help SDP munging, many web developers are going to have
> to keep swinging that hammer, no matter how much it hurts.

I think I need to do some reading up because the info must all be there 
among all the mails, but it would really be helpful to have a list of 
things people would like to do, and that currently require SDP mangling.

> But clearly, if you gave them an API that didn't require such pain, they
> would use it.
>     [1]
>      > _____________
>      > Roman Shpount
>      >
>     _______________________________________________
>     rtcweb mailing list
> <>