Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Neil Stratford <neils@belltower.co.uk> Sat, 15 October 2011 12:08 UTC

Return-Path: <neils@vipadia.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 EACF521F8B2B for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 05:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.946
X-Spam-Level:
X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Pu4pfcxLzZpw for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 05:08:46 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2521F8B1A for <rtcweb@ietf.org>; Sat, 15 Oct 2011 05:08:42 -0700 (PDT)
Received: by iabn5 with SMTP id n5so3963456iab.31 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 05:08:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.24.96 with SMTP id u32mr5298360ibb.61.1318680520906; Sat, 15 Oct 2011 05:08:40 -0700 (PDT)
Sender: neils@vipadia.com
Received: by 10.231.200.146 with HTTP; Sat, 15 Oct 2011 05:08:40 -0700 (PDT)
In-Reply-To: <4E996E80.6070500@alvestrand.no>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.com> <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com> <CALiegfnHuYJnX3rnuDGbZPB4NvK=dCTJ=iLcu+zguP5wo_uPqQ@mail.gmail.com> <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com> <CA+9kkMB3p1u7hRX_vO1bQbQ2z-V+0rLiJmi+ZqkEA0mqc66keQ@mail.gmail.com> <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com> <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com> <CABRok6nsVH5tYfwFqQpmjF=Kj-wZQDB9XUX8oOee8r3wr51fKA@mail.gmail.com> <CAAJUQMg79h1=V4m9agq9CcEmFknTaaXrgUz9qtq9EL-0_nChiQ@mail.gmail.com> <4E996E80.6070500@alvestrand.no>
Date: Sat, 15 Oct 2011 13:08:40 +0100
X-Google-Sender-Auth: s75pphGUVkoZqt4RcbfdoY2oYpg
Message-ID: <CABRok6k=8wa_K7X+MHwaii+6ANfTquLqauMKgm7KP82wf6pKyA@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=0015177414280557bc04af553cd6
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sat, 15 Oct 2011 12:08:47 -0000

On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>
>>  Remember that:
> a) codecs are (currently) part of the platform, not of the application.
> b) one of our aims for negotiation is that if application X is deployed in
> browsers A and B, and both browser A and B support a "best codec" W that was
> created *after* X was last updated, then the codec W should be used.
>
> Given the last point - the app *cannot* "implicitly" what codec will be
> used. And given that it doesn't know the codec, it can't know the parameters
> either.
>
> (that said... I'm all in favour of fewer parameters. The RTP format for VP8
> that we're in the process of finishing has zero parameters. I hope it will
> remain that way.


Can we work around this issue by delegating parameter negotiation to the
codec itself? Each codec in the codec capability list could present (at a
minimum) it's name, priority and a codec specific parameter negotiation
function. We can then delegate the complicated codec specific details (when
necessary) without needing any advance knowledge in the javascript
application. We would need to standardise the parameter lists such that
different codec implementations can interop, but that is the same with SDP.

Neil