- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 24 Aug 2011 12:01:41 +0200
- 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*:
m=audio
<stuff>
m=video
<stuff>
In the other case the PeerConnection would want to generate:
m=audio
<stuff>
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.
Harald
Received on Wednesday, 24 August 2011 10:02:09 UTC