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

Iñaki Baz Castillo <> Wed, 19 June 2013 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FDCE21F9E18 for <>; Wed, 19 Jun 2013 09:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.654
X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mGeL18Jdddkq for <>; Wed, 19 Jun 2013 09:10:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::231]) by (Postfix) with ESMTP id 07AD621F9E16 for <>; Wed, 19 Jun 2013 09:10:29 -0700 (PDT)
Received: by with SMTP id n1so3092806qcx.8 for <>; Wed, 19 Jun 2013 09:10:29 -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:content-transfer-encoding:x-gm-message-state; bh=VhhFCc9TvdJpDyhI5a3Ps+/US2zjLQ13DbIidJ+FgjI=; b=D3TXIZSdf67d+SucfGg8YDfBq21qOSXTQ4YQitFOsbqgX96NMfqwynB0doDat2nfCs 5j5YzXyTq0VyT6VZzI5cuVvTRZs7Gqy/YP8l2mRqGU6Hq8MVtN1OkIaSJ20GnaAuPVrm C/gR9psE2BNCqKA6Mjc1hK91M5HqOrtQyJRAOQ4VkPnZL1DrSn4/SNDAcazkC76w3L+n QFKSf+eTKm93tbMrBxDJuyMi+PJEL2XDo96EkzyZF0attFUYcxiFlWsgbaH+/8Fe3/es P0pM559a9vmrhePcjbw3oXvZsRurtrahbr/Tn+VFC8CPqUb3yZX3M6DtsjPt+bw606HC vrKQ==
X-Received: by with SMTP id d20mr4391444qey.33.1371658229031; Wed, 19 Jun 2013 09:10:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jun 2013 09:10:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Wed, 19 Jun 2013 18:10:07 +0200
Message-ID: <>
To: Peter Thatcher <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnnMeFswOy0Kxmr3qyoTFsz9zX2sQLL20YxfJ/LVFFnJwU4RSBn1zC2UOFqjhWHm3OoKyQq
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:10:34 -0000

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).

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. 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.
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.

> 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 you
> 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 wrap
> 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

>> 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 through
> SDP".  I think that's a clear requirement.  So why don't you just say that?
> 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 mean without parsing the SDP blob and splitting it into blob fragments).

Best regards.

Iñaki Baz Castillo