IETF Logo Mail Archive

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

Harald Alvestrand <harald@alvestrand.no> Sat, 15 October 2011 11:29 UTC

Return-Path: <harald@alvestrand.no>
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 E0E9921F8B48 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 04:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Rb8XyBCgIjx6 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 04:29:08 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 133E721F8B3F for <rtcweb@ietf.org>; Sat, 15 Oct 2011 04:29:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AD8939E0BF for <rtcweb@ietf.org>; Sat, 15 Oct 2011 13:29:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN6O6Hn5Gmap for <rtcweb@ietf.org>; Sat, 15 Oct 2011 13:29:05 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 22D1239E051 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 13:29:05 +0200 (CEST)
Message-ID: <4E996E80.6070500@alvestrand.no>
Date: Sat, 15 Oct 2011 13:29:04 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
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>
In-Reply-To: <CAAJUQMg79h1=V4m9agq9CcEmFknTaaXrgUz9qtq9EL-0_nChiQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 11:29:09 -0000

On 10/15/2011 11:59 AM, Wolfgang wrote:
> First, the draft is not about SIP vs XMPP vs xy. All those protocols
> try to be general and necessarily suffer from feature creep and
> complexity. SIP once started as a much simpler alternative to H.323
> and look where we are now. XMPP has defined more than 300 extensions.
> But I think there is not much disagreement about the call signaling
> part.
>
> The question is if we can get rid of SDP as well. If both sides
> *implicitly* know what codec parameters they are going to use there is
> no longer the need to negotiate them. If caller and callee use the
> same RTCWEB client this should be doable. The RTCWEB server may need
> some hints about the browsers capabilities -- eg does it support a
> camera, is the bandwidth limited -- to provide it with an applicable
> RTCWEB client. But we don't need a way to convey and negotiate dozens
> of codec parameters.
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.)
> If we insist on interoperability between RTCWEB client A and RTCWEB
> client B we will end up re-inventing SDP and/or SIP.  And of course we
> will have to keep RTCWEB and SDP standardization in sync.
We absolutely insist on interoperability between browser A and browser 
B, if both are runnning applications that want to communicate.

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.
>
> Wolfgang
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.29.0 | Report a Bug | By Email | System Status