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:02 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 E3CAD21F8C00 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level:
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 ZtoZeeMyeCzY for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 15:02:19 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C375721F8A5E for <rtcweb@ietf.org>; Thu, 7 Mar 2013 15:02:18 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id ek20so1100724lab.30 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 15:02:17 -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=4hCIJjzDLVKaWloxYVJzOOPXJwhul/7iOPOswscP1jk=; b=kDhh1vVlG3X+gjPS7YOyw/12tnqdJLQg4p25yxQB9cCgsFHY2XkRhNbC52oCRlLl2y qzns58D+ctERImWQFwQUnzr+Eo2QfafKS5Ztp9E42BG8qa8Cqv3h1xcpWdy8WbqSX/zV J18ro+Xw9m3wHp/dydJNZSCv1dmZjNUnjvKMpCeIkw6wWT//zKgdeBZtotrfMoewhxdw ntkvYuYfRW2DKLoqGMGHVIgX4cIOSEcbPw2Eg+ciHV5Rn7FHGzLR4tGK5qWGd2wiM/Y6 Q55+LEv/cPJnbL/JMH/sG0jxr63HV1EQXxDQv5+fDDETZu6UJrpYPusuEjpW1ZeH//Wf GM1g==
X-Received: by 10.152.104.80 with SMTP id gc16mr30225106lab.49.1362697337453; Thu, 07 Mar 2013 15:02:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 15:01:56 -0800 (PST)
In-Reply-To: <51390B3C.7010203@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>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 8 Mar 2013 10:01:56 +1100
Message-ID: <CAHp8n2=95ymNRHNC2dxZGszZqh+4P=5xYn0-_JKV+fT_z7VMcQ@mail.gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary=f46d040714d5bc46ad04d75db2d8
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:02:20 -0000

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  ?

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.

Cheers,
Silvia.