IETF Logo Mail Archive

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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Sun, 10 March 2013 21:10 UTC

Return-Path: <silviapfeiffer1@gmail.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 38CBF21F88A1 for <rtcweb@ietfa.amsl.com>; Sun, 10 Mar 2013 14:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 PjtLdC-H9QnX for <rtcweb@ietfa.amsl.com>; Sun, 10 Mar 2013 14:10:53 -0700 (PDT)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1409421F87E4 for <rtcweb@ietf.org>; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id gg13so2599007lbb.2 for <rtcweb@ietf.org>; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=w3zpRnXBJWi2tL3DgiRdUHKNGKWTeUdQB1fTA8RSLnQ=; b=vhHoIykxYX5FxZk1AHYQbv8/XCc0x1xWpER784NT+b8vaENx+vU7sLzlFlUWv2FuT8 hk4SU4He8QgHZ3spA4OKx9pJplJyf8S2QEGTjI/n4dhaBmZcydcULMfG+8uUhFVMl/0k Q+vnhRHi9vFjymw+spHAivLNnfxO1tA5TS6zr/cjU0M3NPONRnUxCzS2VKV536c5a/Yt R9GkHqqNSxk3KwpLwpjj7BDWcfDiHCurTSuDiKHZuVK13KWnrnEhRKYPZ6+w9rNe8sDQ sW4fXPepT+vnMxGNXa7ak8rD7AtXEwOWlr4swckv0RVnk7LBywT7koVT77Tiv4OXm/xt Lnag==
X-Received: by 10.112.83.133 with SMTP id q5mr3710485lby.25.1362949852013; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Sun, 10 Mar 2013 14:10:31 -0700 (PDT)
In-Reply-To: <513B5D98.2070601@alvestrand.no>
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> <513B5D98.2070601@alvestrand.no>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 11 Mar 2013 08:10:31 +1100
Message-ID: <CAHp8n2n8xMEYMLKNbRT73=SSvJ9ku8b_KKL+AqJyx9F0R8_GqQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="f46d04016c2dc6afc204d7987dfd"
Cc: rtcweb@ietf.org
Subject: Re: [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 21:10:54 -0000

On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> 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.
>

TBH I just hadn't seen
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html.
Is it implemented anywhere yet?

Now that I've looked at it, I wonder how that interacts with the SDP
created through createOffer(). If indeed the JS programmer never has to
touch the SDP, I don't see a need to expose it in the API at all, i.e.
setLocalDescription() should not be necessary.

Silvia.

v2.23.0 | Report a Bug | By Email