[rtcweb] (resend) RE: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)
Matthew Kaufman <matthew@matthew.at> Sat, 20 October 2012 17:21 UTC
Return-Path: <matthew@matthew.at>
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 5DE6021F87CB for <rtcweb@ietfa.amsl.com>; Sat, 20 Oct 2012 10:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.685
X-Spam-Level:
X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A4wbI+TaOFD for <rtcweb@ietfa.amsl.com>; Sat, 20 Oct 2012 10:21:53 -0700 (PDT)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id A513921F879D for <rtcweb@ietf.org>; Sat, 20 Oct 2012 10:21:53 -0700 (PDT)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 7BC9D148096 for <rtcweb@ietf.org>; Sat, 20 Oct 2012 10:21:51 -0700 (PDT)
Message-ID: <5082DDAF.7080102@matthew.at>
Date: Sat, 20 Oct 2012 10:21:51 -0700
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="------------020704050602070205060608"
Subject: [rtcweb] (resend) RE: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)
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, 20 Oct 2012 17:21:54 -0000
(Resending from my personal account as the list server dropped a bunch of messages and I will be resending from my personal account a few that I think are still particularly relevant) Harald Alvestrand [harald@alvestrand.no]: > > Because making an interface that makes following an existing practice > easy (but does not enforce all the constraints of that practice) is > better than making an interface that makes following that practice > very complex? If this myth were correct, it would be a good argument. In practice, the JSEP interface (which claims to loosely follow an existing practice) is *more difficult* to use when interoperating with endpoints that actually follow that practice than the API we proposed does. In our testing, the amount of Javascript required to unpack the pile of SDP that is emitted by an existing implementation of JSEP (the Google Chrome beta), pick it apart into what you actually need to interop with a real gateway endpoint, exhaustively test what SDP can then be put back in to setLocalDescription and setRemoteDescription (as there is no specification saying what SDP is and is not allowed here, and no error reporting to speak of), and then the signaling on top of that all adds up to more than twice as much Javascript as it takes to use our proposed direct-manipulation API, create SDP that is compatible with the far end you are interoperating with, and start media flowing. If the existing API actually had a description of what SDP is and is not acceptable, and specified an error reporting mechanism that was actually helpful for developers, then it would *still* take 2x the Javascript to call any endpoint other than one of your own because of the need to manipulate the SDP and the need to implement a state machine in Javascript while the browser is also keeping a bunch of state internally. I encourage anyone who cares about interoperability to replicate our experiment... build an application using the Chrome beta that calls a gateway speaking SIP for signaling and ICE-lite for consent verification and see how "easy" it is or isn't. Matthew Kaufman
- [rtcweb] (resend) RE: Relaxing SDP O/A (was RE: A… Matthew Kaufman
- [rtcweb] SDP testing (Re: (resend) RE: Relaxing S… Harald Alvestrand
- Re: [rtcweb] SDP testing Bernard Aboba
- Re: [rtcweb] SDP testing Matthew Kaufman
- Re: [rtcweb] SDP testing Harald Alvestrand
- Re: [rtcweb] SDP testing Bernard Aboba
- Re: [rtcweb] SDP testing Cullen Jennings
- Re: [rtcweb] SDP testing Matthew Kaufman