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

Tim Panton <tim@phonefromhere.com> Wed, 05 October 2011 10:00 UTC

Return-Path: <tim@phonefromhere.com>
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 BA71721F8BB3 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 03:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 h7miseaUQx1m for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 03:00:53 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8D21F8BA4 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 03:00:52 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id C8AB237A903; Wed, 5 Oct 2011 11:16:47 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-19-199418076
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CALiegfnx=qoS_pqyC45WVEYEFqj-3eP9g_kyhAUaOO6He_UEfw@mail.gmail.com>
Date: Wed, 5 Oct 2011 11:03:54 +0100
Message-Id: <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>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
X-Mailer: Apple Mail (2.1084)
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:00:53 -0000

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.

Tim.