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 13:00:18 +0200
Message-ID: <4E54D9C2.6000205@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2011-08-24 12:54, Harald Alvestrand wrote:
> 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 ----
Looking at http://dev.w3.org/2011/webrtc/editor/webrtc.html, A side 
would here do addStream with an audio only MediaStream, while B would 
add a MediaStream with audio and video.
> or
> Initiator   ---->  Audio ----->  Responder
> <---- Audio ------
Both adds audio only streams.

I don't see the problem.
> 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 11:00:42 UTC

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