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

Re: Additional requirement - audio-only communication

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 24 Aug 2011 12:54:31 +0200
Message-ID: <4E54D867.4060706@alvestrand.no>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: public-webrtc@w3.org
On 08/24/11 12:10, Stefan Håkansson LK wrote:
> On 2011-08-24 12:01, Harald Alvestrand wrote:
>> On 08/24/11 09:52, Randell Jesup wrote:
>>> On 8/23/2011 1:32 PM, Stefan Håkansson LK wrote:
>>>>>>> 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").
>>> I'm confused: why would not this be handled in the Offer/Answer phase?
>>> (either within SIP if we use it, or within Offer/Answer if we don't
>>> use SIP).
>>> Accept m=audio, reject m=video
>> It would be handled in the offer/answer phase, I think; the problem that
>> got me to raise the issue was generating the offer.
>> In one case the PeerConnection would want to generate *in the offer*:
>>     m=audio
>> <stuff>
>>     m=video
>> <stuff>
>> In the other case the PeerConnection would want to generate:
>>     m=audio
>> <stuff>
> Somehow the sending web application get's to know that the other end 
> only wants to receive audio. Why not then, instead of cluttering the 
> PeerConnection API, generate a MediaStream containing audio only? 
> Those tools are already there in 
> http://dev.w3.org/2011/webrtc/editor/webrtc.html
> If the MediaStream added to PeerConnection contains audio only, of 
> course this would be reflected in the SDP generated.
No, this does not compute; I thought so too initially, but I don't think 
it works any more.

If the configuration the initiator wants can be either:

Initiator   ----> Audio -----> Responder
<---- Audio ------
<---- Video ----


Initiator   ----> Audio -----> Responder
<---- Audio ------

then the fact that the initiator adds only an audio stream doesn't help 
in figuring out whether the SDP offer should have a m=video section or not.
Received on Wednesday, 24 August 2011 10:55:01 UTC

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