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:26:07 +0200
Message-ID: <4E54DFCF.4000805@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2011-08-24 13:20, Harald Alvestrand wrote:
> 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?
A side would offer audio only. B side would offer audio and video. 
Remember that what is offered is sendonly (see step 16 i section 4 of 
the spec), and offered individually, so what B offers is not a result of 
what A offers, but rather determined by the application.
> 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:26:42 UTC

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