Re: [rtcweb] codec and connection negotiation

Harald Alvestrand <harald@alvestrand.no> Wed, 10 August 2011 06:23 UTC

Return-Path: <harald@alvestrand.no>
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 252B321F85B8 for <rtcweb@ietfa.amsl.com>; Tue, 9 Aug 2011 23:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.109
X-Spam-Level:
X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 OoyaaXsLymae for <rtcweb@ietfa.amsl.com>; Tue, 9 Aug 2011 23:23:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA821F85B9 for <rtcweb@ietf.org>; Tue, 9 Aug 2011 23:23:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DB4E39E155 for <rtcweb@ietf.org>; Wed, 10 Aug 2011 08:22:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P+yaOOC8USk for <rtcweb@ietf.org>; Wed, 10 Aug 2011 08:22:33 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 23D1139E03C for <rtcweb@ietf.org>; Wed, 10 Aug 2011 08:22:33 +0200 (CEST)
Message-ID: <4E4223EF.3000600@alvestrand.no>
Date: Wed, 10 Aug 2011 08:23:43 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA67422A.1CAD4%henry.sinnreich@gmail.com>
In-Reply-To: <CA67422A.1CAD4%henry.sinnreich@gmail.com>
Content-Type: multipart/alternative; boundary="------------010605070207000302090002"
Subject: Re: [rtcweb] codec and connection negotiation
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, 10 Aug 2011 06:23:18 -0000

On 08/10/2011 02:59 AM, Henry Sinnreich wrote:
> Leaving all the problems behind mentioned here for SDP (in full 
> agreement), the bigger picture is that apps may have so many other 
> types of data to exchange, besides codecs.
> For example numbers, sizes and types of screens, keyboard/touch 
> devices to optimize user experience, data for mashup parts of the 
> screen, say surround sound(?), etc.
> Folks not wedded to SDP use metadata to exchange app info. Why should 
> RTC continue to inhabit a world of its own, even in the browser?

> Naïve question:
> Does this separate use of SDP to convey RTC metadata not contradict 
> the target universality of apps in the browser?

Sorry, I can't parse that sentence.

On one possible parsing, my response would be "no more than the use of 
UTF-8 to convey human names constrain the naming conventions of humanity".
(Prince, in his "symbol" phase, might not like it, though. No way to 
please them all.)

Seriously, if codec/stream-related metadata needs to be conveyed in one 
standard format, it seems that we're either using SDP or reinventing it. 
And so far, the reinventors seem to be unable to gather a consensus to 
go forward.

Other metadata doesn't seem (yet) to require one standard format.


>
> Thanks, Henry
>
>
> On 8/9/11 12:18 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
>
>     Paul Kyzivat said:
>
>     > Certainly it would be possible to provide an API that had something
>     > semantically equivalent to SDP while using a different syntax.
>     But thata
>     > comes at the price of having to then track future extensions to SDP.
>     >
>     > An alternative is to profile/subset SDP and then perhaps develop
>     a new
>     > representation semantically equivalent to that. The trouble with
>     that is
>     > interoperation with things that don't fit the subset. Going that way
>     > will probably require making it pretty easy to extend the subset
>     when
>     > things that had been excluded are found to be needed.
>     >
>     > (It gets worse if you decide to "add a few things" to the API that
>     > aren't part of standard SDP.)
>
>     [BA]  Given the discussion of IETF 81, my concern is that the API
>     is based on  an SDP and ICE profile that is implicit and not
>     explicit.    In a number of cases, it would appear that this
>     implicit profile may ignore normative requirements (including
>     MUSTs) in RFC 3264, 5245 and other relevant RFCs.
>
>     The danger in continuing down that road is  that different
>     implementations will make different assumptions about the profile,
>     and the result will be implementations that are not only
>     incompatible with each other, but also with existing
>     implementations of the wire protocols.
>
>
>     ------------------------------------------------------------------------
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb