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 13:20:46 +0200
Message-ID: <4E54DE8E.9080207@alvestrand.no>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/24/11 13:00, Stefan Håkansson LK wrote:
> 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.

But what's in the SDP Offer that Initiator sends?
remember that in an Answer, the responder cannot add capabilities that 
the initiator did not include.

>> 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:21:24 UTC

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