Re: [rtcweb] Additional requirement - audio-only communication

"Timothy B. Terriberry" <tterriberry@mozilla.com> Fri, 26 August 2011 00:00 UTC

Return-Path: <prvs=2124d5069=tterriberry@mozilla.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 7F4D021F8BF0 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 17:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.522
X-Spam-Level:
X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 nCR2p7-3ltW6 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 17:00:33 -0700 (PDT)
Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id EB2BA21F8BA9 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 17:00:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAAHhVk6sGgRS/2dsb2JhbABDhEyiYoFYgUABAQQBIxVAAQULCxgCAgUWCwICCQMCAQIBRRMBBwKHbqhukViBLIQPgREEh2GQNg+MDg
X-IronPort-AV: E=Sophos;i="4.67,429,1309752000"; d="scan'208";a="168683092"
Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip3o.isis.unc.edu with ESMTP; 25 Aug 2011 20:01:46 -0400
X-UNC-Auth-As: tterribe
X-UNC-Auth-IP: 63.245.220.240
Received: from [10.250.5.61] (corp-240.mv.mozilla.com [63.245.220.240]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p7Q01eql005874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Aug 2011 20:01:45 -0400 (EDT)
Message-ID: <4E56E264.8000600@mozilla.com>
Date: Thu, 25 Aug 2011 17:01:40 -0700
From: "Timothy B. Terriberry" <tterriberry@mozilla.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110604 Gentoo/2.0.14 SeaMonkey/2.0.14
MIME-Version: 1.0
References: <4E539A1F.109@alvestrand.no> <4E53B80C.20304@ericsson.com> <4E53E0C8.6010304@alvestrand.no> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA7F62@ESESSCMS0362.eemea.ericsson.se> <4E54ADC7.8030407@jesup.org> <4E54CC05.1040705@alvestrand.no> <4E54CE29.2060605@ericsson.com> <4E54D867.4060706@alvestrand.no> <4E54D9C2.6000205@ericsson.com> <4E54DE8E.9080207@alvestrand.no> <4E54DFCF.4000805@ericsson.com> <4E54E24F.7060906@alvestrand.no> <4E56707B.104@skype.net> <4E567737.6020101@jesup.org> <4E5680B0.6070702@skype.net> <CAOJ7v-0DnVKYD2gd4os3R-LuzN1mu4qZqjndDEJcJXwY7U-FnA@mail.gmail.com>
In-Reply-To: <CAOJ7v-0DnVKYD2gd4os3R-LuzN1mu4qZqjndDEJcJXwY7U-FnA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, public-webrtc@w3.org
Subject: Re: [rtcweb] Additional requirement - audio-only communication
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: Fri, 26 Aug 2011 00:00:33 -0000

Justin Uberti wrote:
> I think it makes sense for the browser to emit capabilities, which could

I agree there's clearly some gaps here that need to be filled.

> then be used by the web app to generate a SDP offer or answer. This

> The original problem that started this email is one specific example -
> if the callee application wants to only receive audio, the application
> can generate an audio-only SDP based on the offer, the browser

I think the Harald's original problem was the other way around: the 
_caller_ wants to only receive audio, and needs to generate an SDP 
_offer_ that says that, even if the browser is capable of receiving 
video. I don't think that invalidates your point, though.

> capabilities, and the desired app behavior - without any new APIs in the
> browser.

But I'm not sure what you mean by "without any new APIs"... in your 
approach, something has to be able to enumerate the capabilities in 
sufficient detail for the webapp to generate SDP by itself. I don't 
think there are any existing APIs that go that far.

You also need an API to tell the browser what to actually do. The 
current PeerConnection approach is passing in the offer or the answer. 
If you're generating the answer, you need some way to tell your browser 
what you answered. For the "please don't send me video" case this is not 
an issue... it'll simply never arrive. If you want to change what the 
local browser is sending out, however, then it is.

I do agree it eliminates the need for an API to tell the browser what 
kind of SDP to generate, but it also seems like it imposes a pretty big 
burden on application developers: even if you keep the 
currently-proposed PeerConnection ability to generate SDP as the "simple 
API", the moment you want to do something slightly more complex, you 
have to add code to generate the appropriate SDP, which necessarily 
involves figuring out all the capabilities of the various browsers on 
various platforms. Maybe I'm naive in thinking that seems like an awful 
lot of work just to say, "Please don't send me video."