IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 18 June 2013 22:52 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533B611E80E1 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 15:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.653
X-Spam-Level:
X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-xuL6g-NwE for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 15:52:22 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BF47011E8112 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 15:52:22 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id m15so2638631qcq.19 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 15:52:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=Kv8eR5g4ERMCU8GWCGTQB9SiWV2HVQZJW92a1/uKMlw=; b=EgvSjsUw9h6Ma1dxsDtTfp4h7jJoBO57Qq1+YnzADI2yDBBUTbexNUIjMkGAc+nzcG ncCralsQrctQ5alrkP55QLu45+wScY6hxXUvw5C2qlaq7cySNyOWVZ+jgMh4AsLdyZXO UZQUUQfA84EhpAemn0uVFofIbcK+6WrxvXMkBXNZQ6wlpQqNx+zEyw1KBdl2R3ZH/LvM sI/NukWq7qVm4uNM3CaqkEUiqY2+fpDsP654ODhMpiX+kSPF1PrduaWMFvpuF9KlaBTa xCPRUP7sZclJLEvLVEmamabMfNmNB0jpHYPZW3piA6SaXtYLdtXIwkQR7WdguOuKoKkh tDCA==
X-Received: by 10.49.81.244 with SMTP id d20mr32709qey.33.1371595935771; Tue, 18 Jun 2013 15:52:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 15:51:55 -0700 (PDT)
In-Reply-To: <CAD5OKxtKbUYtdtaTg26nKUxK_UFHch1JU+yw1iH4iZ5Atbz=OA@mail.gmail.com>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CA+9kkMDk2L3SBPC08WU_5RcL16-Wzv8Mocj3-Qzmxz2E24ERGg@mail.gmail.com> <51C0C1A0.9010107@nostrum.com> <CAJrXDUGqSvsosZJhcRR-kCwEX1g_wvPnSZPmmcNwggk+Z9WNCA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAD5OKxtKbUYtdtaTg26nKUxK_UFHch1JU+yw1iH4iZ5Atbz=OA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 19 Jun 2013 00:51:55 +0200
Message-ID: <CALiegfkp6vf+EYtA0cNfj-9p59pmjZcMFtq_c=tw5r3xYwKhaQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmGgfJVObyOOlmjtEFGCpX3TC+9++yXgdOXY3BAQqcgc7owFaUPbYEewFZr4FwQqYaCkLxj
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 22:52:23 -0000

2013/6/19 Roman Shpount <roman@telurix.com>:
> 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.


Very good point. That exactly what we need: something like a JS
wrapper of the native internal media API.



--
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email