W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

RE: Additional requirement - audio-only communication

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 23 Aug 2011 19:32:45 +0200
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D61C1BCA7F62@ESESSCMS0362.eemea.ericsson.se>

>>> A18  It MUST be possible for an initiator or a responder Web application
>>> to indicate the types of media he's willing to accept incoming streams
>>> for when setting up a connection (audio, video, other). The types of
>>> media he's willing to accept can be a subset of the types of media the
>>> browser is able to accept.
>> When do you think this should be indicated? I guess that in most cases
>> the establishment of a connection is foregone by some signaling (I
>> would like to communicate, would you?). Perhaps what media you would
>> be willing to receive can be agreed in this phase, and the sending
>> application would react by sending only the desired media. This way
>> there would not be a need to have specific APIs for this purpose.
>I think the PeerConnection will have to be told before it sends off its
>SDP Offer.
I agree. I was referring to signaling between the web apps happening before the creation of PeerConnection. One way to solve this would be to have such signaling ("I would like to communicate, would you?", "yes, but I only want audio") happening before creating the PeerConnection objects, using a mechanism outside the scope of this standard. That way the applications would have this knowledge when doing "addStream" (or even "getUserMedia"). 
>Having properties on the PeerConnection that one can set (with default
>"audio video") is one possible API.
That would be another way.

A third way, a bit uglier, would be that the user that would like to receive only audio only tells the local application only. The received stream would initially contain both audio and video, but only the audio would be rendered (since the app knows the user's preference). Using the media re-negotiation mechanism the video would over time be downscaled to a very low bitrate since it is not being rendered.

Received on Tuesday, 23 August 2011 17:33:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC