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

Stefan Håkansson LK <> Fri, 26 August 2011 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A6CE21F88A0 for <>; Fri, 26 Aug 2011 00:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.256
X-Spam-Status: No, score=-7.256 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LOeZ1Zrx5Eyd for <>; Fri, 26 Aug 2011 00:13:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D8F021F87F0 for <>; Fri, 26 Aug 2011 00:13:33 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-e3-4e5747e7a42e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 26.73.02839.7E7475E4; Fri, 26 Aug 2011 09:14:48 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 26 Aug 2011 09:14:47 +0200
Message-ID: <>
Date: Fri, 26 Aug 2011 09:14:47 +0200
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= <>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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: Fri, 26 Aug 2011 07:13:36 -0000


this is how I would do the case of the caller (initiator) wanting to 
receive only audio, but willing to send audio and video with the current 
API proposal:

1. Generate an audiovisual mediastream (getUserMedia)
2. create PeerConnection, add the above mediastream (addStream)
3. combine the SDP received from PeerConnection with the following 
fields "This is an invitation to a communication", "sending audio and 
video", "want to receive only audio" into a message sent to the peer.
4. the app in the peer (same app!) receives the message, reads the 
fields, (given user agreement to start the communication) creates a 
PeerConnection, feeds the received SDP into the PC, generates an *audio 
only* stream (getUserMedia) and adds it to the PC
5. A couple of SDP exchanges later the application is working as 
intended. (there will be onaddstream's, you will attach those streams to 
video/audio elements etc.)

Quite simple! And no need to have the application read, understand, or 
modify, the SDPs - they are opaque. (Then, of course, the mediastreams 
must be mapped to RTP sessions and such stuff, but I'm sure that is 
solvable and should not be visible in the API IMHO.)


on 2011-08-26 06:48, Justin Uberti wrote:
> On Thu, Aug 25, 2011 at 8:01 PM, Timothy B. Terriberry
> < <>> wrote:
>     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.
> I meant, without specific APIs for that specific use case (i.e. "create
> an audio-only offer"). We would need some sort of GetCapabilities API
> that returned a blob of all the session description options the browser
> supported, which probably could be formatted as a uber SDP offer if that
> made parsing simplest.
>     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.
> Yes, you need a "HandleLocalDescription" and "HandleRemoteDescription"
> API, instead of just a single OnSignalingMessage API. The deviation from
> the current flow is fairly minor, you just have 2 additional states in
> the state machine.
>     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."
> It's a fair point, there is more complexity involved in generating the
> offer, but in our experience it is manageable. I suppose it depends on
> how many APIs we decide we need to control the generation of SDP  (i.e.
> use cases other than no-video). If we decide we need to control crypto,
> resolution preference, codec preference, we may find this approach simpler.
>     _________________________________________________
>     rtcweb mailing list
> <>
>     <>