[rtcweb] WebRTC JS object API with SDP shim option

Robin Raymond <robin@hookflash.com> Thu, 20 June 2013 16:55 UTC

Return-Path: <robin@hookflash.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 BE74121F9E8F for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 09:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.014
X-Spam-Level:
X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 2saRtkNIKrB4 for <rtcweb@ietfa.amsl.com>; Thu, 20 Jun 2013 09:55:02 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C436821F9E8B for <rtcweb@ietf.org>; Thu, 20 Jun 2013 09:55:02 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id e11so17489337iej.29 for <rtcweb@ietf.org>; Thu, 20 Jun 2013 09:55:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=E4hhg2EGA2u9cQTIijijpo5R0XCliSoIp6OV7pb28ZI=; b=lY49w59fFt+uR6WKMHZfbiFdoeYPocbDg/3eL3wWCf6bIMz387qj4qtxa88RwIIEVc mXcd/0qKya1lUBBTWPId8Xf3D3ShSdBzDFyAR5AhRm68AEA+1qA5t9fuCa2G4StItYCL w7vLFpD0aTu5Fs0loCDL6bWZAKbazWSJ1UxazbFfYosiIE4btXuWWTS4kdWIDdadvmXD aeDOCi+AHO/DciNsvFxAVIQurqGl2XFygFS0Q+m3jbX68YASRGgBjttWHprV2MrniIva v0ARLQ+KWayzthk/le2Mu+jcV5q5/ywHeM6fqIu3V9u+iSqG69LdJlyZCEXE4kO5Q9je lw8w==
X-Received: by 10.50.176.228 with SMTP id cl4mr226504igc.7.1371747302385; Thu, 20 Jun 2013 09:55:02 -0700 (PDT)
Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ct8sm1053404igb.7.2013.06.20.09.55.00 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:55:01 -0700 (PDT)
Message-ID: <51C333E1.1030709@hookflash.com>
Date: Thu, 20 Jun 2013 12:54:57 -0400
From: Robin Raymond <robin@hookflash.com>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="------------080301060004050607050305"
X-Gm-Message-State: ALoCoQkD3O1tGtRqf3UilKF+XN4XVKuXp9Zb5beHR/G9gNRvWI/LOfqGEYoP1NEOv1ng9A0ND/+R
Subject: [rtcweb] WebRTC JS object API with SDP shim option
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: Thu, 20 Jun 2013 16:55:03 -0000

You are right. It's time for those of us who are begging for an 
alternative to SDP to come up with an alternative.

I'm willing to lead such an effort. I just ask others to please have an 
open mind. I absolutely do understand the need for the SIP world to have 
an easy API they can use for SDP. But I also know SDP as an primary 
surface API is making anything beyond a basic calling a requirement to 
mangle SDP as a mechanism to control and obtain properties from an 
underlying media/RTC engine.

I think there is a really good compromise. That is to provide an API 
that will adhere to the security policies needed (e.g. respects the need 
to require ICE establishment), but provides a simple shim API similar to 
what people already have with SDP but not be required to use for those 
who want to a more direct approach.

There's no need to "burn" the entire thing to the ground and start over 
and that is _not_ my desire.

This WebRTC thing must succeed but I can't imagine the W3C accepting our 
proposal for mangling SDP as a primary surface API to do common edge 
case scenarios. WIth an alternative proposal that satisfies both camps, 
I believe they could accept and we can stop the anit-SDP crowd 
grumblings once and for all.

To that end I'm going to write two drafts:
draft-raymond-webrtc-js-object-api-rationale-00 (to explain 
requirements, philosophy, methodology, benefits/pitfalls, use cases that 
are difficult/impossible with SDP+O/A)
draft-raymond-webrtc-js-object-api-00 (to outline the actual API)

Plus, I'll produce a shim on top of whatever API that will allow the SDP 
folks to have a simple SDP based API similar to what exists now but is 
entirely written in JavaScript to prove that this can be done.

I really want a viable solutions for all interested in having a really 
good proposal API to ultimately become accepted by the W3C.

If anyone has anything I should add to either of these drafts or wants 
to be involved, please contact me.

-Robin


Christer Holmberg <mailto:christer.holmberg@ericsson.com>
20 June, 2013 12:55 AM
Hi,


At the virtual interim, the Plan A and Plan B folks were asked to sit 
down and try to come up with a compromise "Plan AB" solution.

I guess it would be good if people that don't want SDP could try to come 
up with a compromise "CU No Plan" solution :)

Regards,

Christer