Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Peter Thatcher <> Wed, 19 June 2013 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B16421F9CAC for <>; Wed, 19 Jun 2013 09:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ILyQAjDcoWak for <>; Wed, 19 Jun 2013 09:41:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0888D21F9C8F for <>; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
Received: by with SMTP id t12so5224099pdi.7 for <>; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
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; bh=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=KdECPIbr94ZUxR+o4IeOQdBPojoUcslM8isSrQURAxYJTmrPtFyK4+QbGPnbGvZc+h leGS538xOg4Nue+ce1BqBjvh1Ek+mfh9gYZkhlVQBAxWzsTZcJQ3SQWTdlVQbTYDrsHh 6vSbihGLMBhQsxFpFnkdkGX2qsGHeS7BXmFxVOLVOf67FRNB08OZUTZi/IIpeSbpAFtQ CPJQN0o3GUQ1E76e46MgUY+lDW7DQ0iYzSAvyiry9N6dTwqjlS6lDvOfkv5rBKk049CD cJEPJizVE8YrX/pA67wOlNnmeKh55oKkkv9pSDJreM0NnlKB5XlqzRQnwjbzaR5q/bCe pN7w==
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=en0KuSmihrtIC1EssnlryKUgjy8dstN+BSQAATTDmiQ=; b=Ni75X54lrEtboSZ9wg/sW8Kxpr2g5/pyPHsZSVerw32dRB6toAIocSA1Lwc5iM2G+3 kX4HI6KGZolWmNufJcJ0hy5qFQSZE6hp1PPenfBBjJ6XelEhDkjJ5KgKrBaok0ZfxjGq zvIlGyzntVD8olsfyF2RawoXbDmk2sHq16+FY5jOO9S6O/qYq12ZIuUmoGfBxiKxioLq W3hZQpgCLu+b74bgjBQ5eWkqd+M08QZLrAIEipVCrUYvzLJPSnRw170DVc7SYBNGbfx3 lt6pkv5d0LuS0ro9w7ObPKe92LDEPepb7vAFtgH1CQw9yO8+0gaDDMgcxbLHz7mbMxeH iB3Q==
X-Received: by with SMTP id zd4mr7579324pac.141.1371660097731; Wed, 19 Jun 2013 09:41:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jun 2013 09:40:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Peter Thatcher <>
Date: Wed, 19 Jun 2013 09:40:57 -0700
Message-ID: <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="047d7b15fea3e0d45804df848058"
X-Gm-Message-State: ALoCoQkYDkc/g5o81iPkwDftenGjhcv6J3F8oPqAt74/oCleAIKnULsh4I2m1FhB6lFjZVRPicLQ2m7oZMrGCWAiGE0W/HcKGFImsSo5ta4s3perXuFXn+fdb4n8v4fIcoynhzLJOMpwb120vmgHXPvUdjTuB1mOrjpMgbgMLx6y2v8rfEZddxUPYTlMdQN8uBDKjCemp49k
Cc: "" <>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
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: Wed, 19 Jun 2013 16:41:43 -0000

On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <> wrote:

> Hi Peter, for now just some comments (I agree that more use cases and
> other considerations must be provided):
> >> I don't think that the discussion is just about "SDP O/A usage in the
> >> API". We don't want a replacement for SDP, nor a new representation of
> >> SDP, nor to deal with blob strings between the JS layer and the WebRTC
> >> layer.
> >
> >
> > Please at least agree with Christer that this is about the API, not about
> > the signalling wire format.  The API already allows whatever signalling
> wire
> > format you want,
> IMHO that is not entirely true.
> First of all, whichever the signaling protocol is, it must accomplish
> with SDP O/A semantics (since it must carry a SDP and receive a SDP to
> establish the communication).

API calls must use the SDP O/A, but what goes on the wire doesn't have to
be.  With enough SDP hackery, you can do whatever you want over the wire,
including not use O/A semantics.

> Second: Indeed the current spec does not mandate what should be sent
> in the wire. In practice that means we can use SIP over WebSocket,
> XMPP/Jingle over HTTP, or whatever. But in practice it also means that
> we must send a SDP in the wire. The SDP blob string can be
> hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
> string generated by PeerConnection-A should arrive to
> PeerConnection-B.

A sufficiently smart chunk of JS could call
setLocalDescription/setRemoteDescription with SDP that it completely
created itself, and send whatever it wants over the wire.

> And since such a SDP is generated by the WebRTC
> stack and passed to the JS as an unmanageable blob string, the JS app
> cannot properly deal with it.

The JS parse the SDP from createOffer/createAnswer, get the info it needs,
make decisions and then serialize different SDP back down in
setLocalDescription/setRemoteDescription.  It's terribly ugly, but it works.

> So, currently WebRTC does not mandate the signaling protocol
> in-the-wire, but it does mandate the media signaling protocol
> in-the-wire (you need to pass a working SDP to the remote, sure),
> something that constrains the signaling protocol itself.

It does not mandate SDP over the wire.  It's possible to write a JS app
that gets everything working with no SDP on the wire.  It's anything but
pretty, but it works.

> and everything you mention from here on out is just the
> API.  So please just say to Christer "yes, this is all about the API".  It
> will make the rest of the discussion much more clear.

> Ok, this is all about the API :)

>> In short we want something like a JS wrapper of the native
>> WebRTC API,
> I work on the WebRTC implementation in Chrome, and I don't know what you
> mean by "native WebRTC API".  Such a thing does not really exist.  The
> implementation has three different layers of abstraction, each of which
> might be referring to, but none of them which will give you what you want.
> The highest level uses SDP.  The lowest level gives you media bits, but no
> ICE, SRTP, DTLS, or SCTP.  The middle layer gives you all those things
> without SDP, but it still uses an abstract offer/answer for transport and
> RTP setup (and even has a Jingle implementation on top of that).  None of
> those give you what you want.  The "native WebRTC API" that you want to
> doesn't exist.

> Ok, IMHO nobody is still requesting a specific JS API but just
> describing the features and capabilities such an API must provide. The
> "similar to native WebRTC API" is just a comment to help understanding
> what we mean, but of course each browser is free to implement its
> native API(s) as it prefers so the "JS wrapper" concept does not make
> sense.

But you can't say "similar to native WebRTC API" because no such thing
exists.  You can't be similar to something that doesn't exist :).

>> to directly manage media/transport parameters and media
>> streams without having to pass a monolithic and unmanageable SDP blob
>> between the JS and the WebRTC layer.
> That boils down to "the same power of the current API, without going
> SDP".  I think that's a clear requirement.  So why don't you just say
> Would save everyone a lot of reading and misunderstanding.

> You are right.

>> calls to get the required media parameters, the JS can send them to
>> the remote peer in the way it prefers (which may be via a SDP created
>> by the JS app, or via an AJAX request for sending codecs/media-types
>> info followed by a WebSocket connection for sending ICE candidates one
>> by one, or serialized in JSON via a previously open DataChannel
>> session... or whatever mechanism available in the Web and browsers).
> You already have that.

> Can I first send my codecs list, then (once the peer notifies me
> codecs compatibility) send the codecs preference order, then my ICE
> candidates and later (not just when ICE process terminates) signal the
> peer a "OK" message so we both start the multimedia audio/video/data
> communication, all of this with the current API?

I think so, yes.

> (I mean without parsing the SDP blob and splitting it into blob

Maybe... I don't know for sure.  But generally, anything beyond the most
basic uses of the API requires at least some SDP hackery, and advanced uses
require a lot.

Best regards.

Iñaki Baz Castillo