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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Thu, 07 March 2013 23:53 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 BDEE021F86EA for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:53:07 -0800 (PST)
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=[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 6WISNn2ipPco for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:53:06 -0800 (PST)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68121F86EF for <rtcweb@ietf.org>; Thu, 7 Mar 2013 15:53:06 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id l12so911181lbo.33 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 15:53:05 -0800 (PST)
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=KrTP5lx9PxXBswXLyS6/64Q9MPCsvcJOhhs15GLXFlA=; b=nOEGh58JqMHtt8tFLvo2Xx3VN5apk8MdsQaju5HOoEa1u40Co5cesOWrWBdzxfpxI9 8U8jxXztx52m18sLNAeidhI7BBY7K9fY2L90zh58e8oxMBEtK+7SYyW4VscKmBJxmyCK au0b68JjPFDR5p3Yga9nHCNsclIRRp8a/cefBSnuDn6cYYoq9nhBXsWDl3+AN7mNLfYT myPHChFtEp/LHf09klEsRjw1VhbnlJzimAwgh/A0Xpq3k+ppJew6j+YsmoQG3zoNDnWB jNX2DYZea8BEa13SB5uUNXgs2GfujFHMxAx2C+2WN0KCqrNmyD6vPysD20RCBaWwgB3n XZnw==
X-Received: by 10.112.103.196 with SMTP id fy4mr229074lbb.125.1362700385115; Thu, 07 Mar 2013 15:53:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 15:52:45 -0800 (PST)
In-Reply-To: <51391E5E.4080007@matthew.at>
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> <51391E5E.4080007@matthew.at>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 8 Mar 2013 10:52:45 +1100
Message-ID: <CAHp8n2kDuiT+rJD7wZi3N=1JCzT+-5dF7Bp-YFtynP_cUhxqtA@mail.gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary=f46d0401f93763ea9e04d75e68dd
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:53:07 -0000

On Fri, Mar 8, 2013 at 10:10 AM, Matthew Kaufman <matthew@matthew.at> wrote:

>  On 3/7/2013 3:01 PM, Silvia Pfeiffer wrote:
>
> On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman <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 many features of this proposal and I would love to see it a good
part of it integrated with the existing API.



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


So, in your opinion what should change in the SDP offer/answer semantic to
allow for a better API for Web developers along the lines of the above
linked proposal?

Silvia.