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

Randell Jesup <randell-ietf@jesup.org> Thu, 25 August 2011 16:25 UTC

Return-Path: <randell-ietf@jesup.org>
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 1B54421F84D7 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 09:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
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 SulOU7s0Hswx for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 09:25:39 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 415A521F84DA for <rtcweb@ietf.org>; Thu, 25 Aug 2011 09:25:36 -0700 (PDT)
Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1QwclV-00022g-Ed; Thu, 25 Aug 2011 11:26:49 -0500
Message-ID: <4E567737.6020101@jesup.org>
Date: Thu, 25 Aug 2011 12:24:23 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: public-webrtc@w3.org, "rtcweb@ietf.org" <rtcweb@ietf.org>
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>
In-Reply-To: <4E56707B.104@skype.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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: Thu, 25 Aug 2011 16:25:40 -0000

On 8/25/2011 11:55 AM, Matthew Kaufman wrote:

> On 8/24/2011 4:36 AM, Harald Alvestrand wrote:

Re: negotiate offer/answer separately in each direction


>>
>> I think that:
>> a) this doesn't make sense - it's a completely new SDP/RTP practice,
>> and we should not depart from established practice without a good
>> reason; it also flies against the "keep the number of RTP sessions as
>> low as we can" conclusion that came out of all the discussions about ICE.
>> b) it's not consistent with section 4.1.2 step 7.
>>
>> I think step 16 of section 4:
>> "If connection's ICE started flag is still false, start the
>> PeerConnection ICE Agent and send the initial offer. The initial offer
>> must include a media description for the PeerConnection data UDP media
>> stream, marked as "sendrecv", and for all the streams in localStreams
>> (marked as "sendonly")."
>>
>> is neither correct nor complete.
>
> I agree that "this doesn't make sense" and it is just yet another reason
> that I think SDP offer-answer is entirely inappropriate for WEBRTC.
>
> The web user agent should do what the web site's HTML and cooperating
> Javascript tell it to do. It should not be engaged in direct negotiation
> with the far end such that the outcome is either indeterminate or even
> unexpected, except where direct negotiation is explicitly required to
> meet a security requirement (the initial ICE handshake to determine that
> it is permitted to send data to that endpoint).
>
> Note that any perceived gains by doing this negotiation (like "what if
> my browser is on a slow connection and only wants to receive audio") are
> immediately negated the moment the site changes the SDP enroute to add
> "wants HD-resolution video" for you.

Ok, so that's a bad web-app - don't use it.


Are you really suggesting "send video to someone who doesn't want it anyways"?


"perceived gains" - sending me video at (say) 500K or more plus audio at<50K,
when I'm on a 128K link will kill my connection until I can somehow get the
other side to back off.  Horrid user experience.  Remember people without
broadband or with limited broadband will be using this.  What if I have 768
down, 128 up - but Johnny in the his bedroom is watching youtube videos or
downloading torrents, etc?


> In addition, because the spec is currently written with offer-answer, a
> wide array of use cases that would be possible if capabilities were
> instead exposed via Javascript become impossible. As an example, it
> should be possible for me as a web site developer to create a page that
> can determine, without prompting you to use your camera, whether or not
> a camera is available and if so what codecs it supports. That way I can
> put "I see you have a high-resolution camera and can encode H.264
> video... click here to call a live agent who can help you find the exact
> replacement part" for users who have that, and not if they don't have a
> codec that works with my call center or a camera with sufficient
> resolution to examine the parts I sell.

In what way is that use-case blocked by offer-answer?  Access to the video
needs user confirmation; access to capabilities info shouldn't.  And so the
page can generate an offer with audio and video, or just audio if they have
no camera.  A user declining to send video doesn't necessarily mean you
don't negotiate it - they advertise receive-only for video (if the web app
wants to).


You state above there are major possibilities blocked by offer-answer (I can
think of some minor issues that with O-A require a second O-A pass) - can you
detail some use-cases so we can see the benefit and not just the assertion?
Then we could balance that against the advantage of O-A being well-speced and
known and implemented.  (And the issues surrounding how well and how
interoperably web-app developers can implement their own capability
negotiations/etc)


-- 
Randell Jesup
randell-ietf@jesup.org