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

Peter Thatcher <> Wed, 19 June 2013 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B65921F9D5E for <>; Wed, 19 Jun 2013 08:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.732
X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 q69NvAEdqz+3 for <>; Wed, 19 Jun 2013 08:47:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::233]) by (Postfix) with ESMTP id A242521F9D22 for <>; Wed, 19 Jun 2013 08:47:16 -0700 (PDT)
Received: by with SMTP id lf11so5246817pab.24 for <>; Wed, 19 Jun 2013 08:47:16 -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=PdsgXqCo8V4k2c6pm/7nU2gNWaht6ABr5nL/BmnHyHk=; b=AUl57kZtXqNOOPLfHWsAOxGqrXl4pe0EbzThCT9dZDzN/Wr/6SCJA7FlmrbPgFXGDN mtzv/Df+ElC94Rwwue2/t5uywCXlbSPb4qq2w5niyDf8pRIO/JPGN4TaCwbHz19jz6UM 6pqLjnRUkvByxrNlEko0LPuyRHsapaFMhBSVFB7pvoCgltJbHQx4aF8LmGroqzjal/tz BWxFaD4qEX4ZkiVVcanh1Ysk0IxGjeGNnf7Kz90XQRr6p2M4R3lPuiNlCLl+WqynpA+8 +bGrP6+EUmSlYKs2AN5EA5+9GmEi11V55wvGrK13g5fL6zqjGohSlpivEpPOIHjIesy6 bgIQ==
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=PdsgXqCo8V4k2c6pm/7nU2gNWaht6ABr5nL/BmnHyHk=; b=IBoT0QSQySryQ1BIMsKpu+Db+Ez8JKUMptrTsMtQO6S/Cm4tX6nbPQpCwIIX8mgDqT O9M/LeiFlsE5VGZGpg9MUEHeZ8vicXW14CSsVGwBh0spUaTToQIuiIWnvoYGbO2HKRDS zem4wmu7972AK2JKRN481zzdntYzbMsHqBmygVR764yF+C1bUpLrVduFwUVE5W2B8++e JUPsqsYyWYS8iSadztZ1+ps134Rhkp+lpbDQfqRKQwhYw/lF80gt+25NE+yJ+H8AEt9o sxhXsSUZi3P0xJtmx1Ksnyhc5pLssNzQZttFA9POwuXWNP2l1hUYa4YgIA7vke1Flfzn 0ShQ==
X-Received: by with SMTP id 2mr3432430pbp.150.1371656836274; Wed, 19 Jun 2013 08:47:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jun 2013 08:46:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Peter Thatcher <>
Date: Wed, 19 Jun 2013 08:46:36 -0700
Message-ID: <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="bcaec53148177af8fd04df83beab"
X-Gm-Message-State: ALoCoQmp0VdbZEqJRiXhV4BztbcK9QStFedzWZxwjrtldv0+hE06W0NwqgfFUfw0Zm5S3gJfflnPLcru1u8w3Em8kJnQwvEJBlJgQrGZZXt1Q0EWRiaQ2spZiXMgyoQfC3Cph+zyVTJe5e6YGnPV6BWtfx7VMS34MmfANRaiD8MvJLhEnvOmFAvNeShcf5QOAe/hZLKqSwbD
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 15:47:17 -0000

I put some comments inline, but I'd like to offer a few suggestinos to all
of those in the "SDP Rebellion" fighting the "SDP Empire":

- A clear, succinct description of what you need and why is a lot more
useful and will lead to more progress than long rants about what you hate
an why.

- The WG usually likes use cases.  Do you have any real world uses cases
that the current API doesn't provider, or that makes painful?

- It would be helpful to minimize the diff to the current API that you
need.  Saying "blow up everything and do it how I want" is hard do swallow
(witness comment 22).  Saying "here's a small change that would relieve a
lot of pain" might make more progress (although even not's clear if even
that's possible).

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

> 2013/6/19 Christer Holmberg <>:
> > We need to be very clear what we talk about, or some people are always
> going
> > to be confused :)
> >
> > So, AFAIK, the discussion is about SDP O/A usage in the API, only in the
> > API, and nowhere but the API.
> >
> > Whatever people us on the wire is outside the scope.
> Hi Christer,
> I do not dare to summarize what we request in a single response, and I
> don't want to say something that "I didn't want to say" ;)
> IMHO this thread clearly describes what we request, i.e. in these exact
> mails:
> -
> -
> -
> My "non-normative" summary:
> 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, 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.

> In short we want something like a JS wrapper of the native

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.

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.

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.

> For sure, other participants in this thread can improve/fix my "summary".
> Please. re-read the 3 links above, IMHO they should clearly describe
> what we are requesting for :)
> Best regards.
> --
> Iñaki Baz Castillo
> <>
> _______________________________________________
> rtcweb mailing list