Re: Additional requirement - audio-only communication

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