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 12:01:41 +0200
Message-ID: <4E54CC05.1040705@alvestrand.no>
To: Randell Jesup <randell-ietf@jesup.org>
CC: public-webrtc@w3.org
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*:


In the other case the PeerConnection would want to generate:


Since the generation of SDP happens within the PeerConnection 
implementation, which is part of the browser, the code that generates 
the offer has to know which of those two to generate. And since it 
cannot infer the intent of the Web application, it has to be told somehow.

That's the requirement I was trying to capture: The Web application has 
to tell the browser.

Received on Wednesday, 24 August 2011 10:02:09 UTC

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