Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Iñaki Baz Castillo <ibc@aliax.net> Wed, 05 October 2011 10:06 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 D1B1121F84DF for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 03:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.634
X-Spam-Level:
X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 Q5-RH4PXA-tu for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 03:06:54 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F166A21F8BE5 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 03:06:50 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so1438515vcb.31 for <rtcweb@ietf.org>; Wed, 05 Oct 2011 03:09:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.186.134 with SMTP id fk6mr2034241vdc.380.1317809397877; Wed, 05 Oct 2011 03:09:57 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Wed, 5 Oct 2011 03:09:57 -0700 (PDT)
In-Reply-To: <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com>
References: <CA+9kkMBi9BzDu=WOq3RG-o5nbfnUTftDg3LRBU3DFh=Kc4W5ZQ@mail.gmail.com> <CALiegfmYgQ+yb=pDp1J2_PVa1SkxTOuaUCM02Vt6-iGabwif1g@mail.gmail.com> <CA+9kkMCUTiPO3eASjn0mbRA9YCF6TMmGGOjQ4NkVkvzVMN39Gg@mail.gmail.com> <CALiegfnx=qoS_pqyC45WVEYEFqj-3eP9g_kyhAUaOO6He_UEfw@mail.gmail.com> <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com>
Date: Wed, 5 Oct 2011 12:09:57 +0200
Message-ID: <CALiegfk_6pviBMBmYUvj69JA73Uy0rnXaMvThPuGT2R5NOWycQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Wed, 05 Oct 2011 10:06:54 -0000

2011/10/5 Tim Panton <tim@phonefromhere.com>om>:
> On 5 Oct 2011, at 10:19, Iñaki Baz Castillo wrote:
>
> - Now please generate my SDP as a reply for the received SDP:
>
>  var my_sdp = WebRTC.SDP.answerFor(remote_sdp);
>
> - ...but discard the video offered by the peer.
>
>  my_sdp.removeStream("video");
>
> It seems to me that by calling WebRTC.SDP.answerFor() - getting the native
> code
> to do the 'compatibility matching' you've lost quite a lot of influence over
> the selection process.
> Lets say this is a conference app on an android phone - and lets say that
> the phone supports
> h 261, h263 and h264 but only has hardware accel for h264 - the app's screen
> layout is such that
> we only want a postage stamp of the remote user and a still image would be
> preferable to a
> poorly rendered moving one (less distracting) . (so I'd like h264 or
> nothing)
>
> How does the app express that set of preferences in your scenario?
> If the app gets all the capabilities data as JSON objects, it can make
> decisions itself,
> eliminating the ones that don't fit the usecase even though they do actually
> 'match'.
> That's why I'd like to see the matching and elimination done in javascript,
> with the data
> presented in a JS friendly manner. It can then be converted to SDP for
> sending over the
> (web-socket) wire if needed.


Hi Tim, honestly I didn't expect to define the full WebRTC JS API in 5
minutes while I was writting the mail :)

Your points are perfectly valid and should indeed be covered. But I
didn't want to be so explicit in my immature API suggestion. It was
just an overview.

Regards.

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