Re: Additional requirement - audio-only communication

On 08/24/11 13:26, Stefan Håkansson LK wrote:
> 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.

As we talked about on the phone - this would require that we keep media 
for the two directions in separate RTP sessions, negotiated in separate 
SDP offer/answer exchanges.

I think that:
a) this doesn't make sense - it's a completely new SDP/RTP practice, and 
we should not depart from established practice without a good reason; it 
also flies against the "keep the number of RTP sessions as low as we 
can" conclusion that came out of all the discussions about ICE.
b) it's not consistent with section 4.1.2 step 7.

I think step 16 of section 4:
"If connection's ICE started flag is still false, start the 
PeerConnection ICE Agent and send the initial offer. The initial offer 
must include a media description for the PeerConnection data UDP media 
stream, marked as "sendrecv", and for all the streams in localStreams 
(marked as "sendonly")."

is neither correct nor complete.

I think we need to conclude on the "Mapping of media streams" topic 
before we can write it correctly.
But I'm going to pause this thread now until the people who wake up 
later have had a chance to comment....

                 Harald

Received on Wednesday, 24 August 2011 11:37:16 UTC