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

Wolfgang <wolfgang.beck01@googlemail.com> Sat, 15 October 2011 12:58 UTC

Return-Path: <wolfgang.beck01@googlemail.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 359EA21F8AA8 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 05:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8+dw+EZTptxp for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 05:58:25 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2121F8A7D for <rtcweb@ietf.org>; Sat, 15 Oct 2011 05:58:20 -0700 (PDT)
Received: by pzk34 with SMTP id 34so1736169pzk.9 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 05:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZI6xc/kOoZcBjgjCoVxrni3uI/n42TW9AjoPj2hy/pY=; b=qKZs8FGGoYYBG0ia+FmbM8FCb6HdDFtvM3kaVjIG8eeyFAJ4xWQhPQtmuFIV1RX15q LWdAmh+AXWSniVdUVD1oM+EvjlljNO/jmdamsMlCW/A5NRZgSGlOFX38UGX+WkA722Cg OGFAjKRRpAv6QT8w7eX4eDD1XnyDdp+8EJlMY=
MIME-Version: 1.0
Received: by 10.68.39.231 with SMTP id s7mr16167907pbk.33.1318683500416; Sat, 15 Oct 2011 05:58:20 -0700 (PDT)
Received: by 10.68.55.230 with HTTP; Sat, 15 Oct 2011 05:58:20 -0700 (PDT)
In-Reply-To: <CABRok6k=8wa_K7X+MHwaii+6ANfTquLqauMKgm7KP82wf6pKyA@mail.gmail.com>
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> <CABRok6k=8wa_K7X+MHwaii+6ANfTquLqauMKgm7KP82wf6pKyA@mail.gmail.com>
Date: Sat, 15 Oct 2011 14:58:20 +0200
Message-ID: <CAAJUQMgWsqP2GVuMFgWywUwy1ZiSpm-Cnhk=sV09qpW9UoTruw@mail.gmail.com>
From: Wolfgang <wolfgang.beck01@googlemail.com>
To: Neil Stratford <neils@belltower.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
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:58:26 -0000

On Sat, Oct 15, 2011 at 2:08 PM, Neil Stratford <neils@belltower.co.uk>; wrote:
> On Sat, Oct 15, 2011 at 12:29 PM, Harald Alvestrand <harald@alvestrand.no>;
> wrote:

>> 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.
Is this goal worth all the complexity introduced with codec negotiation?

>> (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.
That's nice if it really stays that way. MPEG2 had this, too. But then
people started using it in ways that haven't been anticipated and it
turned into a horrible mess.

>> We absolutely insist on interoperability between browser A and browser B, if both are runnning applications that want
>> to communicate.
No disagreement here.

>> Whether RTCWEB client A wants to communicate with RTCWEB client B should be entirely up to them. We're here >> to make it possible, not here to make it mandatory.
What does this requirement cost us in terms of complexity? If we have
to replicate SIP's and SDP's functionalities, it might be not worth
it.

Neil Stratford wrote:
> 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.
Do you mean moving codec parameter negotiation into the RTP stream? It
would require
transcoding if your media stream leaves RTCWEB. And you are just moving the
complexity to a different part of the system..


Wolfgang