Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

Matthew Kaufman <matthew@matthew.at> Thu, 07 March 2013 23:10 UTC

Return-Path: <matthew@matthew.at>
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 BBBB021F8484 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.351
X-Spam-Level:
X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001]
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 OZ0DlMx+W10o for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:10:27 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5821F8464 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 15:10:25 -0800 (PST)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 4FCE6148049; Thu, 7 Mar 2013 15:10:23 -0800 (PST)
Message-ID: <51391E5E.4080007@matthew.at>
Date: Thu, 07 Mar 2013 15:10:22 -0800
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CAJrXDUGSMfQ=SNrSxKVvay=4JUXHULy0cO2pRN9+iFJ23doWZQ@mail.gmail.com> <CAJrXDUHvcsuN6vXs8wku_aUrs-siHdn2wBDOJBgpgDPJySgdSg@mail.gmail.com> <CABcZeBMt7vaMnhcDD0-U7n6Hn-T=sHcGUGEV4=vAs8DVcoi-CQ@mail.gmail.com> <CAJrXDUGqxDxS5=_YnLOWVT6xOgXYuspGS5U2gXevc+PP2vLdHw@mail.gmail.com> <CALiegfnZKVOgmh_5Qb2HeXuAL1BdxDc=U-=t1NfEEMC4DHMUew@mail.gmail.com> <CAJrXDUEK9DCMfxOoq-8HPQwjTZrVvW-CEZJzte_gzyUs16hJuw@mail.gmail.com> <CALiegfmTWZ0dDjfuUixL3nOpZ0LEs30TSOi1iFw7MW94qkD-JQ@mail.gmail.com> <CAJrXDUFy4u5B5AmG8xGN5SfNOe4HduJFunvQC_ht=5NOUYYjLA@mail.gmail.com> <CAD5OKxt0DmadedrS1fGT_gnGboxeFx9hhBoTGLkxk0vy01K0Kw@mail.gmail.com> <51390B3C.7010203@matthew.at> <CAHp8n2=95ymNRHNC2dxZGszZqh+4P=5xYn0-_JKV+fT_z7VMcQ@mail.gmail.com>
In-Reply-To: <CAHp8n2=95ymNRHNC2dxZGszZqh+4P=5xYn0-_JKV+fT_z7VMcQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000806070600020408010504"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
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: Thu, 07 Mar 2013 23:10:30 -0000

On 3/7/2013 3:01 PM, Silvia Pfeiffer wrote:
> On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman <matthew@matthew.at 
> <mailto:matthew@matthew.at>> wrote:
>
>     On 3/7/2013 1:46 PM, Roman Shpount wrote:
>
>         I do not think redefining session description is the best
>         approach. Having access to direct API methods that control
>         send codecs, send media types, resolution, etc  is easier to
>         understand and to program. I think even simply exposing the
>         API from Voice and Video engines in current WebRTC
>         implementation would be a more usable API then the current
>         offer/answer SDP based one.
>
>
>     There is an existing proposal published by my employer which is
>     along these lines. It might be helpful if the folks who are just
>     now realizing what the issues are with dealing with both the
>     complexity of the format of SDP as well as the embedded
>     offer-answer semantics could review that and see how closely it
>     matches their needs, rather than starting from a clean sheet of paper.
>
>
> I assume you're referring to:
> http://www.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype ?

No, I was referring to 
http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm

>
> I like some of the approaches taken in this proposal.
> I like that there are actual objects for RTCSdpType and 
> RTCSessionDescription .
> There are, however, no functions to manipulate a SDP yet.
>
> I assume that the API discussion has to happen in the W3C and not 
> here? To be honest, I am not overly fussed as to what format the 
> browser deals with - SDP or JSON - though the latter is a more natural 
> browser format. I do, however, care what the Web developer has to deal 
> with.

The web developer currently is stuck with SDP *and* the SDP offer/answer 
semantics *plus* whatever gets added in MMUSIC to SDP in order to 
actually do everything that's needed (bundle, stream identification, 
etc.)... assuming that the changes to SDP can be made while keeping them 
compatible with everything else that already uses SDP.

Matthew Kaufman