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

Randell Jesup <> Thu, 25 August 2011 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B54421F84D7 for <>; Thu, 25 Aug 2011 09:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SulOU7s0Hswx for <>; Thu, 25 Aug 2011 09:25:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 415A521F84DA for <>; Thu, 25 Aug 2011 09:25:36 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QwclV-00022g-Ed; Thu, 25 Aug 2011 11:26:49 -0500
Message-ID: <>
Date: Thu, 25 Aug 2011 12:24:23 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To:, "" <>
References: <> <>, <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Additional requirement - audio-only communication
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

Randell Jesup