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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Tue, 16 July 2013 13:43 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 75D7121F85C3 for <rtcweb@ietfa.amsl.com>; Tue, 16 Jul 2013 06:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.262
X-Spam-Level:
X-Spam-Status: No, score=-5.262 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 SsOfVaG3YDLa for <rtcweb@ietfa.amsl.com>; Tue, 16 Jul 2013 06:43:02 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6236021F85B4 for <rtcweb@ietf.org>; Tue, 16 Jul 2013 06:43:01 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-54-51e54de307de
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DD.2E.06741.3ED45E15; Tue, 16 Jul 2013 15:42:59 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 15:42:59 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg==
Date: Tue, 16 Jul 2013 13:42:58 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3157F7@ESESSMB209.ericsson.se>
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> <CALiegfmvfJGp_ydO9CuQT+t0bguNYBU0pZYejD-_wn3nrq-JZw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre5j36eBBvO2GVhM32djMePCVGaL tf/a2R2YPc41vGf3WLLkJ5PHrSkFAcxRXDYpqTmZZalF+nYJXBlTT7cyFcwTrbjz6yB7A+Nf gS5GTg4JAROJXTePMUPYYhIX7q1n62Lk4hASOMwo8ebqc2YIZxGjxMmOpWwgVWwCgRJb9y0A s0UELCVuzL0JVMTBwSzgIzF3syJIWFigSmL54WPsIGERgWqJJf3lENV6El0Xt7KA2CwCqhJL rv8Gm8Ir4Cux8Nh0qFXHWCUu394DlmAEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc81NGiEi8f /2OFsJUkGpc8YYWo15O4MXUKG4StLbFs4WtmiGWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEj yypG9tzEzJz0csNNjMDYOLjlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsX8Ol7zCvvWnjp3l3jHvpIHDd05pnXKh2XduPgq+t23nN4GoPewTTr+o+rg3 8fiOrj3ZG8XWRyo6e69YcCfq1qvDr8s28mYLvPwbppzkazih60nrCXUGW3Vm5s9zXh3/kxng YnJ76SSH+jUKis/zkmQXWTZ/nnqjLddtz92+5JRc137O9xoTLiqxFGckGmoxFxUnAgD+yUiw WwIAAA==
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.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: Tue, 16 Jul 2013 13:43:08 -0000

On 7/8/13 10:43 PM, Iñaki Baz Castillo wrote:
> 2013/7/8 Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>;:
>>> So, was there ever a consensus that "developers MUST NOT
>>> touch SDP"?
>>
>> No, developers are free to touch the SDP (and probably must in certain
>> cases).
>
>
> Do you feel how much painful is "touching a browser generated SDP"? To be clear:
>
> - JS requests "A" to browser.
> - Browser returns "A" (in the form of unmanageable blob).
> - JS modifies "A" to send "A-bis" in the wire.
> - Remote peer receives "A-bis" and replies "B-bis".
> - Both JS app are lying to their respective  browsers to get the
> desired behavior.
>
> This is really painful, really.

I've been doing:

- JS requests "A" to browser.
- Browser returns "A" (in the form of unmanageable blob).
- JS modifies "A" to send "A-bis" in the wire to a system not 
understanding "A" as is
- Remote end receives "A-bis" and replies "B-bis".
- JS modifies "B-bis" (using parts of "A" in the process) and applies 
"B" to browser

Not nice and clean for sure, but quite doable. JS is nice for text parsing.

But the big problems I experienced were:
* "A" was different between different browsers (in a way that the JS had 
to be different)
* "A" would change in ways breaking my code between versions
* What would accepted for "B" would also vary.

Most of this would presumable go away once we settle on exactly how SDP 
should be used (assuming SDP stays).

But all that said, I still think we need API surface that makes the need 
to mangle the SDP an exception (OTOH, perhaps interop with legacy - as I 
did - is an exception? Depends on where you come from I guess.).

>
> In the other side, as I explained in other thread (may be in this
> one?) adding some methods to the current API (to avoid playing with
> the SDP) is not the way to go. A specification in which the JS app
> does not know what he is sending in-the-wire (a blob generated by the
> browser) is doomed to failure.
>
> Please remember that mandating SDP (plain SDP) means that no other
> media signaling protocol can be implemented in future WebRTC apps.

I think Peter Thatcher had an idea of an API extension where you could 
do away with SDP if you want to.

>
> SIP phones have *fixed* code and *fixed* logic. This is no longer true
> in the Web.
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>;
>