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: Wed, 24 Aug 2011 12:10:49 +0200
Message-ID: <4E54CE29.2060605@ericsson.com>
To: public-webrtc@w3.org
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.


>
> Since the generation of SDP happens within the PeerConnection
> implementation, which is part of the browser, the code that generates
> the offer has to know which of those two to generate. And since it
> cannot infer the intent of the Web application, it has to be told somehow.
>
> That's the requirement I was trying to capture: The Web application has
> to tell the browser.
>
>                     Harald
>
>
Received on Wednesday, 24 August 2011 10:11:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 August 2011 10:11:20 GMT