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

Roman Shpount <> Tue, 18 June 2013 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0160821E80E0 for <>; Tue, 18 Jun 2013 15:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.410, 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 a7zi7bBS2bHX for <>; Tue, 18 Jun 2013 15:40:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) by (Postfix) with ESMTP id 02C4911E8114 for <>; Tue, 18 Jun 2013 15:40:34 -0700 (PDT)
Received: by with SMTP id z11so70435wgg.1 for <>; Tue, 18 Jun 2013 15:40:34 -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=zNGz+jw/C6cTTsEqf7AMPbOOmiZm+10LmzHPdg3fupM=; b=Mb5i38ZntTDKxwg8gPz7QcNXGIRACm9NsJ84RWVZyk5jjApL557IEtyDZx+UwIO3jY /ZNLvQuX4M1CUulySaYtXc1kOX/N88yXGbPW/fcEJ3vJovtCIKa4UtHK16Fvraraxw4r oB9addpwb+cBZf2JdeyFhikkhycDs9q1lVLgtVZmx+sdpkW202Gp2/z2Y6dGpCEhvS8n QM6JvhkSseEml965g2jGAUEsVN4yWLb6yYoSjp1JaoUIu3AQ1TcQeO1aC42RBgxv3fpO aPC1/63ubBrz2c3S2jVFALte8WZ0y1mnPLsRcA1e3WXg9xQuT5rInGOEVdOSC+x2vkx3 U9Sg==
X-Received: by with SMTP id es10mr29797wjd.17.1371595234116; Tue, 18 Jun 2013 15:40:34 -0700 (PDT)
Received: from ( [2a00:1450:400c:c03::231]) by with ESMTPSA id r9sm5316160wik.1.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:40:33 -0700 (PDT)
Received: by with SMTP id m19so3878283wev.36 for <>; Tue, 18 Jun 2013 15:40:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id kx4mr11587wjb.33.1371595232432; Tue, 18 Jun 2013 15:40:32 -0700 (PDT)
Received: by with HTTP; Tue, 18 Jun 2013 15:40:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 18 Jun 2013 18:40:32 -0400
Message-ID: <>
From: Roman Shpount <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="089e012292e29b078a04df756602"
X-Gm-Message-State: ALoCoQmvjyKi9X60qkUs/SakbhvBB71IxBr2Od7zSKJx8y2931K1lKqYFEQCa56GgzUvf4HuKGGa
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: Tue, 18 Jun 2013 22:40:36 -0000

One thing I got to mention is that there is already an API used internally
in current WebRTC implementations: Voice and Video Engines. Both of those
take external network transports (which also have their interfaces defined
and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be
used to receive/end media and how this media is encoded. The APIs provided
by these components are fairly typical for the media library APIs that are
used to build SIP and other real time communications clients. In fact these
very APIs were used by (at least at some point in the past) Skype, Google
Talk, Yahoo Messenger and number of other real time clients. I think the
best way to build a usable API is to try to wrap this in JavaScript as
closely as possible instead of building something extremely complicated on
top of them. If we do this, we can create something that will make the job
easier for both browser developers (no complex, hard to test, code which
implements O/A) and for application developers (clear API level contract
with clear mechanisms to control things happening with the media). We
already know that these APIs work for what we need. Let's stop trying to
hide them behind O/A complexity, and then try to invent multiple creative
ways to implement exactly the same functions through all the layers we
built on top.

Roman Shpount