Re: [rtcweb] WebRTC JS object API with SDP shim option

Iñaki Baz Castillo <> Thu, 20 June 2013 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 275ED21E80C9 for <>; Thu, 20 Jun 2013 14:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvaWI5nXnXYA for <>; Thu, 20 Jun 2013 14:27:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::231]) by (Postfix) with ESMTP id 2BB4721E8064 for <>; Thu, 20 Jun 2013 14:27:46 -0700 (PDT)
Received: by with SMTP id hu16so18755qab.8 for <>; Thu, 20 Jun 2013 14:27:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=smu6FQFU1/bJ4OXvHDeCstHu4WtP/3j19fbggtcvtN4=; b=fv4idoYYQIeWgpXfk2OczxYcE7lhMqEvk9Sxdrfz/M24nRoxu/F0TMlQFWNRLnZg2y dYPH4VQY7juBontRGQSCd6c9J4YW1E77EoLYDpiZy75juaSg0R0p5XPyrkXHlZgYofeI DNbq3XV+WRWQO45wgwNVjwmAxspf8IMBm+iK7/nWzQ7HaIhd98xTwQSsJ5Zgl1iVLRUn U5hnW+4IF68J8xeYcHHNS3/biCrPJkE0TzTvTnQ9laMz1UhsDWp/scqMZuhgF15ujUvN JAI3G3elOeiVsGjTj5i7gOIXUUti0jrkuuG70hqbYJIuDOyQYDRelV0djY1MhlzucPJb xktw==
X-Received: by with SMTP id bj9mr11031911qab.14.1371763665604; Thu, 20 Jun 2013 14:27:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jun 2013 14:27:25 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Iñaki Baz Castillo <>
Date: Thu, 20 Jun 2013 23:27:25 +0200
Message-ID: <>
To: Robin Raymond <>
Content-Type: multipart/related; boundary="20cf303b39f1014e1804df9c9ebe"
X-Gm-Message-State: ALoCoQloHjfPhmg/pN/rTqg62dOCRBUNHm8jwa190potuTu8pE6A8F70P3R/ZRqZ3OSX2O6tGKl/
Cc: "" <>
Subject: Re: [rtcweb] WebRTC JS object API with SDP shim option
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jun 2013 21:27:47 -0000

IMHO this is the way to go, something that will make feasible to build any
*future* protocol that just relies in RTP but not on SDP O/A.


2013/6/20 Robin Raymond <>

> 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 <>
>  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
> _______________________________________________
> rtcweb mailing list

Iñaki Baz Castillo