[rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)

Harald Alvestrand <harald@alvestrand.no> Sun, 10 March 2013 03:54 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 7BC8721F85FE for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 19:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.53
X-Spam-Level:
X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, 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 rt+HCcYj9555 for <rtcweb@ietfa.amsl.com>; Sat, 9 Mar 2013 19:54:16 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8B21F85DA for <rtcweb@ietf.org>; Sat, 9 Mar 2013 19:54:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBA6739E194 for <rtcweb@ietf.org>; Sun, 10 Mar 2013 04:54:13 +0100 (CET)
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 juHj9dGTexIU for <rtcweb@ietf.org>; Sun, 10 Mar 2013 04:54:13 +0100 (CET)
Received: from [192.168.255.9] (unknown [216.189.219.66]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1161D39E0E1 for <rtcweb@ietf.org>; Sun, 10 Mar 2013 04:54:11 +0100 (CET)
Message-ID: <513B5D98.2070601@alvestrand.no>
Date: Sat, 09 Mar 2013 17:04:40 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CABkgnnXCio-Dw7dN5yfSjeRf3wG2oWow_M2mU-Y49TedSAPQmg@mail.gmail.com> <CAHBDyN6CFTix3W9qWgC1T0O36t4SajL3hMXaHOdkat-p5TY_xA@mail.gmail.com> <CABcZeBMLdEkFZq5rMOY0texKb4DtFQ-O86JkC17kJihxv6Dj8w@mail.gmail.com> <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@mail.gmail.com> <CAHp8n2nz=NZb=UaevUSS7GRSBpvn-v9_=QHz6iddnZzyx5-TSQ@mail.gmail.com> <CAJrXDUETwfY7ZvaXO_1Bq8gs8pOTgALQE8FiimrUX7sfuEpDsw@mail.gmail.com> <CAHp8n2kcEHcz11LOYYMZ3-nv2PYQKu=z6M=dsQ_H5JuR8ND7hQ@mail.gmail.com>
In-Reply-To: <CAHp8n2kcEHcz11LOYYMZ3-nv2PYQKu=z6M=dsQ_H5JuR8ND7hQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
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: Sun, 10 Mar 2013 03:54:17 -0000

As usual, I'm trying to use subject line change in order to achieve some 
separation of concerns...

On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
> Agreed, but it's also not sufficient. SDP is not "programmer friendly" 
> enough because it has too many details that are protocol-details only 
> and it's too hard to see the semantic bits in SDP and ignore the rest.
>
> For example: the programmer wants to say - I want to get this video 
> resolution, this audio bitrate & channels, I want to use this camera 
> and this microphone for this call. Having to manipulate SDP directly 
> for this is a programmer's nightmare.

I think we've been over exactly those pieces, and our current proposed 
solution is called the Media Stream API and the constraints mechanism - 
and they have exactly nothing to do with SDP, or even with PeerConnection.

I don't think we've got it to be "unproblematic" yet, but also, I don't 
think SDP, JSON or even the offer-answer model is either the problem or 
the solution on this set of functionalities.

Or did I misunderstand something basic?

                Harald