Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Roman Shpount <> Wed, 19 June 2013 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22D0921F9DC5 for <>; Wed, 19 Jun 2013 10:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yArIWP0SRB8m for <>; Wed, 19 Jun 2013 10:17:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) by (Postfix) with ESMTP id 4E18321F9DDF for <>; Wed, 19 Jun 2013 10:17:48 -0700 (PDT)
Received: by with SMTP id j13so4806761wgh.12 for <>; Wed, 19 Jun 2013 10:17:47 -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=9IVMGXwK94Ke5asHGwLilj13ofCpm/DyWIw19MbmeHk=; b=DQ31dTTb/SvbUjXMZtdoCqaeFz4ubsQW8YLUnG9O6IWQ+oaWv3MNWIra8UgZjNTwiE 8IEly7w6itFzhbHtZkpA+x6uzN01wLLhpAQMFQVSraEL9lX4RNXHhX9W2r6D2vLAjFMB maKHz1k0AgRWiOI83wdJAGO9U05NAi9QFGOEklHl1+hsZTDj3dchjzR69zr0yGa5DLtR U3KLimlbJNoSRqgbyCAcYzvM+lQqegqqaGyk6pcDuEPqm5bkyTaUnHKY5kmwGWhUj1ZV cxqwNdA4hUt3RPKfQXle29PsgdeJKKyFvcCEqM44MqWGVKbbzbgMydy7omn01Ctr36DX OIeg==
X-Received: by with SMTP id fu9mr2954173wjb.70.1371662267414; Wed, 19 Jun 2013 10:17:47 -0700 (PDT)
Received: from ( [2a00:1450:400c:c05::22b]) by with ESMTPSA id ay7sm10570247wib.9.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 10:17:46 -0700 (PDT)
Received: by with SMTP id hj3so952454wib.10 for <>; Wed, 19 Jun 2013 10:17:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id kx4mr2931593wjb.33.1371662265682; Wed, 19 Jun 2013 10:17:45 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jun 2013 10:17:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 19 Jun 2013 13:17:45 -0400
Message-ID: <>
From: Roman Shpount <>
To: Peter Thatcher <>
Content-Type: multipart/alternative; boundary=089e012292e21916b504df8502e8
X-Gm-Message-State: ALoCoQnRGUIG0/4BX7y93CgxpUyEHFkdItac7C+8AH0M8yqwmKzbFnzx9aBBeu/ALuxe4T4TYfwB
Cc: "<>" <>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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 17:17:53 -0000

On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher <>wrote;wrote:

> There are two separate things here: 1.  adding to the current API to allow
> JS to avoid SDP.  2.  removing what is there that uses SDP.
> You're saying you want to add new things and remove olds things.  But I
> think really you just want to add what you want, and it would matter if
> what you didn't want to use were still there.  So I think it's better to
> talk about what we can add to the API to make it easier to work with rather
> than talk about starting from scratch.  Removing the existing pieces would
> not be nearly as easy as you make it sound.
Let me approach this from a different angle: Do you think it is possible to
create an interoperable, re-implementable API based on SDP? Currently, SDP
format changes with each release in a way that breaks both SDP mungling
code and external connected end-points. What I want is an API that does not
rely on a string blog to encapsulate every new feature. New features should
be implemented via new methods. I need something standard enough that I can
have a stable application implementation. As it stands right now WebRTC
will not pass the W3C standard process, so we need either spend a lot more
time tying down SDP or create the API that avoids it. I think you
 underestimate the amount of effort needed to finalize SDP. At the current
rate I see this  process taking another 2-3 years. It also creates a
dependency on MMUSIC, which has its own priorities. So, if you want a
realistic API standard, you need to look for a way around SDP.

Also, using SDP just for transport is wasteful. All you need are 3 string
parameters which can be passed individually without parsing/creating a
string blog which carries another 5 things that carry no meaning for
transport (version, origin, etc).
Roman Shpount