Re: [rtcweb] New Draft - WebRTC JS Object API Model

Iñaki Baz Castillo <> Mon, 01 July 2013 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CB7611E8254 for <>; Mon, 1 Jul 2013 13:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T4U6Dw+DqvGS for <>; Mon, 1 Jul 2013 13:38:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E40111E8241 for <>; Mon, 1 Jul 2013 13:38:15 -0700 (PDT)
Received: by with SMTP id hu16so2368473qab.1 for <>; Mon, 01 Jul 2013 13:38:14 -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=flT+uKnwPRR/TV5D4eVAcld1uF9t6e9zfSU1mgvXuws=; b=B6cxqwDVkMtZkyNaIH4AYzVBFmMoQc8S/qKkeLc11CxsjFjF0fJcYn1lM3xB4IrHBu BQtsDj8Fpjq5FbFJUjvGVgyn68srz16/Hwp91/pXlxjNH7oC2hINdcYnbvKnQiqBSt63 tVanm0yhMTjbdCW4AmeSA1rF/Ubj1/VcWzV1gXImEAfuN0KkfxAju3y8qTgsNdYLx1Kh gZHdaXy1he2TYQhquSP7UTwLq8D339WHzV/dvERjQaiB6n3Bo6V48MUZxzsK6mxnTCzS 96cduldW5tHqS6uIPfYTNDyxVkeiS48VrZETExqbkgukD9L3QwyXrYj7g4+cSaLdabmq TXgQ==
X-Received: by with SMTP id g12mr34761246qej.86.1372711094552; Mon, 01 Jul 2013 13:38:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 1 Jul 2013 13:37:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Mon, 01 Jul 2013 22:37:54 +0200
Message-ID: <>
To: Stefan Håkansson LK <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnTFvVsDFc+x9dx4VHzHD1FIjR/5yxeIIxJtD8ITjWea2KLJBrsv8M2XpB5Gx5yblT+5lHB
Cc: "" <>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
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: Mon, 01 Jul 2013 20:38:20 -0000

2013/7/1 Stefan Håkansson LK <>:
> What if first browser generated a JS Object that said (for this example
> we assume one single audio track) it preferred to send audio using
> Opus2.0 but could also do Opus and G.711. If the second browser (which
> has not yet been upgraded) could only decode Opus and G.711, would it
> not have to tell the first browser about this?
> Are you perhaps assuming a capability exchange of some sort before any
> media can be set up?

The fact that a capability exchange or media signaling negotiation
exists does not mean that it must be based on a opaque blob which is
unmanageable at JS level. The JS app should be able to understand
*what* exactly it is sending in-the-wire, and for that purpose a
opaque blob is not a ellegant solution. Instead a JS Object based API
(like *any* WWW API) makes sense. And then the JS app can decide how
to encode/serialize/whatever such a media information in-the-wire (and
yes, it can be into a SDP, but a SDP created by the JS library because
the author chose it, while others can use whatever format or send the
information "splitted" into different requests or whatever.

Of couse the SDP O/A model is a valid model, and of course SIP is a
valid model (which carries the SDP exchange), but that is not the only
one. IMHO the IETF/W3C should not mandate like-SIP-models for every
future RTC applications running in the web.

Best regards.

Iñaki Baz Castillo