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

Cullen Jennings <fluffy@iii.ca> Fri, 19 July 2013 13:56 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 28CE111E8249 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 06:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.434
X-Spam-Level:
X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619]
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 M84iLweEs5Is for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 06:56:53 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 861AC11E81E6 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 06:56:53 -0700 (PDT)
Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45AF950A86; Fri, 19 Jul 2013 09:56:52 -0400 (EDT)
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>
In-Reply-To: <CALiegfmvfJGp_ydO9CuQT+t0bguNYBU0pZYejD-_wn3nrq-JZw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <C02C637E-EEB9-4134-B4B6-1AE8385BC61F@iii.ca>
X-Mailer: iPad Mail (10B329)
From: Cullen Jennings <fluffy@iii.ca>
Date: Fri, 19 Jul 2013 06:56:52 -0700
To: Iñaki Baz Castillo <ibc@aliax.net>
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: Fri, 19 Jul 2013 13:56:58 -0000

Please tell us the use case you have that requires this and it will make it easier to figure out how to solve the pain. 

On Jul 8, 2013, at 1:43 PM, Iñaki Baz Castillo <ibc@aliax.net> 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.
> 
> 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.
> 
> SIP phones have *fixed* code and *fixed* logic. This is no longer true
> in the Web.
> 
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb