Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

Roman Shpount <roman@telurix.com> Fri, 19 July 2013 17:29 UTC

Return-Path: <roman@telurix.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 10B6B21E80B6 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 eV1TJEIRgpXr for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:29:45 -0700 (PDT)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id F24E811E8128 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:29:34 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so4313168wev.14 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:29:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vhYh3IBF5c/Dy4JAUrds8XewwbMC7oTrhvk/c8U7/Zg=; b=HVgWGk2olAqGgGLq6FqsgBLZZlNg95vwwXMfalweIum3Xzai7c0VqNyIA6xSRmbXv1 ZUGBsJYPhkyqfdN8gIcMZ/p6vgci+ewD7ZLYt93XUacnYcQNkdQ1WBlhg3bmmm3fMKWy Pq1SeYeUyRSwYej2Bkb8olSfN55uF6f7AZ+yZnW84z/6ssPIvjZwD03pI5r2V2g+Xuk/ Aw71NVTPVlUBz3qeMpnFoMAbc9VUHjjS54NQ26ZfgmUcMRtG5OUy173C2m+DESAVUk2F ri5uhS+zNHxfpqE+eVG5suZESahgdBKghFqpuKfN5WzuCi75mC3fMcbceQpTdZ6TK801 mCdQ==
X-Received: by 10.180.187.235 with SMTP id fv11mr12102279wic.65.1374254972498; Fri, 19 Jul 2013 10:29:32 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [2a00:1450:400c:c03::22a]) by mx.google.com with ESMTPSA id f8sm4874798wiv.0.2013.07.19.10.29.31 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:29:31 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w57so4318077wes.15 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:29:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.184.12 with SMTP id eq12mr2934957wic.8.1374254970717; Fri, 19 Jul 2013 10:29:30 -0700 (PDT)
Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:29:30 -0700 (PDT)
In-Reply-To: <51E96B5B.2050302@nostrum.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> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CALiegfneUj=kzDjR_E1=S-bqAajaPUE3f_A2g8oGriFyPhamPA@mail.gmail.com> <51E96B5B.2050302@nostrum.com>
Date: Fri, 19 Jul 2013 13:29:30 -0400
Message-ID: <CAD5OKxsgSoRg=OcAKLWZpQNzseW5oSHimoa83LHXegZad4i=sA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary=001a11c3669e5c4faf04e1e0ab5d
X-Gm-Message-State: ALoCoQlGadchcGjuZNQv6LW6mM5JRqU5m3j7CmqlIvivPu5piVGpFH8HC7Yyq5QceMEW2cYz7rkp
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] On babies and bathwater (was Re: 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 17:29:50 -0000

On Fri, Jul 19, 2013 at 12:37 PM, Adam Roach <adam@nostrum.com>; wrote:

> I think this is a hopelessly naïve interpretation of the facts on the
> ground. Simply discarding SDP doesn't magically make the underlying issues
> go away. We would still need to settle a vast number of issues around
> things like simulcast, FEC, codec parameters, indication of supported
> codecs, correlation of RTP streams with MediaStreamTracks, attempts by both
> parties to operate on the same stream simultaneously [1], etc. Basically,
> with very rare exception, the same set of problems that we need to solve if
> we *don't* throw SDP out the window.
>

I would argue that we are not as naïve as you think.

First of all, a lot of the issues you are talking about are not yet solved.
At the same time we have something already working and useful with current
browser implementation. So, what we want is to have these features released
as version 1.0. The problem that we face, that when you implement all the
above mentioned features, even though the API will stay the same, SDP that
it will produce will change, and that will require all, except the simplest
application, and all external components interfacing WebRTC clients to
change. And then when more features are implemented and more different
versions are in use more and more interop for applications and external
components will be required. What we want is an API that is not based on
blob with unpredictable data.

Second, offer/answer and SDP introduce a number of negotiation constraints
that really should not be there. They cause unrelated things to be
negotiated together. It should be possible to negotiate a data connection
and then add and remove media streams without renegotiating the underlying
data connection. To force selection of single codec you need to do two
offer/answer exchanges, which caused by no other reason then framework
limitations. Resolution of glare is restricted to offer back off.
Furthermore, even from the point of view of offer/answer the current API is
broken. It does not allow forking. It introduces a new PRANSWER which is
not a part of normal offer/answer specification. It does not allow change
send media parameters (ie change send codec or send codec parameters)
without doing an offer/answer exchange, which is not necessary with normal
offer/answer framework.

So, what we are proposing is to map exiting implemented browser
functionality to API and get rid of SDP. Ideally we should get rid of
offer/answer as well but if it is too much work we can leave with it for
version 1.0. This way we get predictable behavior based on predictable
input. If we miss some of the future capabilities and they would require
API modification to implement, we can deal with it in 2.0. In API, unlike
network protocols, predictability and testability counts more then ability
for future extension.
_____________
Roman Shpount