[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