IETF Logo Mail Archive

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

"Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil> Sat, 15 October 2011 15:18 UTC

Return-Path: <radhika.r.roy.civ@mail.mil>
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 1567B21F862F for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 08:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level:
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599]
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 GNM6nWuXIV3M for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 08:18:04 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 652AF21F861E for <rtcweb@ietf.org>; Sat, 15 Oct 2011 08:18:03 -0700 (PDT)
Received: from UCOLHP2Z.easf.csd.disa.mil (131.64.100.147) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 15 Oct 2011 10:17:56 -0500
Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP2Z.easf.csd.disa.mil ([169.254.99.133]) with mapi id 14.01.0323.003; Sat, 15 Oct 2011 10:17:55 -0500
From: "Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil>
To: Neil Stratford <neils@belltower.co.uk>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
Thread-Index: AQHMizM3ErWhbt2SxUOIUHEWWONYYpV9g+Lg
Date: Sat, 15 Oct 2011 15:17:54 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil>
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>
In-Reply-To: <CABRok6k=8wa_K7X+MHwaii+6ANfTquLqauMKgm7KP82wf6pKyA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.77.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <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 15:18:05 -0000

Folks:

A given codec type in known, its parameters should also be known per its specifications. So, it the negotiations between codec-types only.

You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here.

Radhika

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Neil Stratford
Sent: Saturday, October 15, 2011 8:09 AM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

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

v2.14.0 | Report a Bug | By Email