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

Roman Shpount <> Mon, 01 July 2013 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDAB211E81EB for <>; Mon, 1 Jul 2013 11:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqdiHgi+2uhM for <>; Mon, 1 Jul 2013 11:24:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C54811E81DC for <>; Mon, 1 Jul 2013 11:24:27 -0700 (PDT)
Received: by with SMTP id j13so3990877wgh.0 for <>; Mon, 01 Jul 2013 11:24:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wP6YPL4xajq+J3wUZugO1Zqbk+lAdL2rP2pbhLM5ZbE=; b=Ld/8TZ+oy5nut8o4BbTV9aIOa2eqt4oLDB7AJLJiDcKvUKcfq2v4uSbKgVpIpb0gT8 NsQPwb5Q7KnmbvxfxqdP+eoMr8bjwhC1pNyGPQMr0voFxYEcqm3QtnJKG0y4dw7pVIH0 8FQ2EWYdGLRZkQ3JzROzWru7xXnKRBc8KAZ7bC+8njJfwfVmRxbHyAnuyswqxJzy6MOM J/1iVIb495EHcHAULgBwl34tADTFfG/FM0dNHmRQ7snWEaQzeIt0pFdNQeWB5Aanjdxj YGxsyi6PomRRBzURUnNMD/RvWflc/Q29k+r+sgYOki0BdhFDlGsH90yfQQtK2lqB5d2b Td1Q==
X-Received: by with SMTP id o8mr21420471wjb.0.1372703067221; Mon, 01 Jul 2013 11:24:27 -0700 (PDT)
Received: from ( [2a00:1450:400c:c00::231]) by with ESMTPSA id h8sm18047354wie.1.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 11:24:26 -0700 (PDT)
Received: by with SMTP id a12so3949005wgh.28 for <>; Mon, 01 Jul 2013 11:24:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id kx4mr20637954wjb.33.1372703065031; Mon, 01 Jul 2013 11:24:25 -0700 (PDT)
Received: by with HTTP; Mon, 1 Jul 2013 11:24:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 01 Jul 2013 14:24:24 -0400
Message-ID: <>
From: Roman Shpount <>
To: Stefan Håkansson LK <>
Content-Type: multipart/alternative; boundary="089e012292e292ca2204e0775632"
X-Gm-Message-State: ALoCoQmGBkz27rKYsvoPLXTx3YSM5K0fL9mANjDUbqiecVjhSoIa1W2zeNQZE4twkn5J+1QhWW1S
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 18:24:39 -0000

On Mon, Jul 1, 2013 at 1:33 PM, Stefan Håkansson LK <> wrote:

> 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?
Any API that we propose would include methods to expose browser
capabilities (ie list of available codecs, with default payload type,
payload name, clock rate, number of channels, and preferred codec
parameters). Generation of SDP c line, rtpmap, and fmtp lines from this
would be trivial, as well as generation of other media descriptions for
XMPP or other negotiation protocols.

In other words, we are not removing the need for negotiation. All we want
is to unbundle it from single offer/answer exchange with single string blob
into separate methods where transport negotiation (ie DTLS, SRTP, and ICE
candidates), mapping transport to streams (ie any sort of bundle related
mapping remote address, SSRC, payload or others), and media
encoding/decoding (ie send and receive codecs, codec parameters, payload
times, etc) are all negotiated separately and independently. This is what
is happening with the API anyway with trickle ICE and no-plan proposal
adding ability to update transport and media parameters once the initial
connection is established. All we want is to extend the same logic to the
initial connection establishment,
Roman Shpount