Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 18 June 2013 00:14 UTC

Return-Path: <bernard_aboba@hotmail.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 3D27721F9E90 for <rtcweb@ietfa.amsl.com>; Mon, 17 Jun 2013 17:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level:
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D4tifpm6E3gs for <rtcweb@ietfa.amsl.com>; Mon, 17 Jun 2013 17:14:04 -0700 (PDT)
Received: from blu0-omc1-s33.blu0.hotmail.com (blu0-omc1-s33.blu0.hotmail.com [65.55.116.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63B7321F9E6B for <rtcweb@ietf.org>; Mon, 17 Jun 2013 17:14:01 -0700 (PDT)
Received: from BLU169-W133 ([65.55.116.7]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 17:14:01 -0700
X-TMN: [wY7vbdkkDCeppRdkhfNB8plnuzP1XNku]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W13367E5FDE396829D364D62938C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_6f3edcda-c2c9-4425-ae23-c803fe464999_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Roman Shpount <roman@telurix.com>
Date: Mon, 17 Jun 2013 17:14:00 -0700
Importance: Normal
In-Reply-To: <CAD5OKxs95gAmYoCr-EB6LaDFW7vaFfpF7=9fu_aCfV=LjwsVpg@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com>, <CABkgnnUmRpanfpwryyiCUsOdMLzrd74n-4LXaj_AK3aLe0yQ8Q@mail.gmail.com>, <51BF5F00.90705@jitsi.org>, <CABkgnnWTvJYG1_HQWz3pZw633rgadeKzx472MTzzFMuq073RgQ@mail.gmail.com>, <CALiegfkZcXrNR3CXY--d4ObZMV2z7NEpgdyVHtVtROVtDQsT6A@mail.gmail.com>, <CAD5OKxs95gAmYoCr-EB6LaDFW7vaFfpF7=9fu_aCfV=LjwsVpg@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jun 2013 00:14:01.0394 (UTC) FILETIME=[BC148920:01CE6BB8]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in 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: Tue, 18 Jun 2013 00:14:10 -0000

 
 
2) Dissadvantages of using SDP in WebRTC.
Roman said:"An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation)." [BA] Hard to argue with this, but I would point out that by far the ugliest part of the monster is the video hindquarters.  While one could argue that we have been living with the warts of SDP for audio and therefore know the workarounds, with video there are substantial interoperability issues, *even among vendors who utilize the same codec*, sometimes even in relatively basic scenarios (e.g. P2P video call with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist yet (at least, based on standards).  So as I see it, it does represent progress that we have contained the SDP monster's impact on the  the data channel, and I welcome Peter's effort to enable applications who don't care about SDP to minimize its usage even if it is not eliminated entirely.