Re: Additional requirement - audio-only communication

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 ----

or

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