Re: Additional requirement - audio-only communication

On 2011-08-24 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).
You can view this from different standpoints.
* One is that the offer/answer phase sorts out this.

*Another is that the offer/answer process phase is there just to set up 
the streams that have been agreed on by some other (non standardized) 
signaling.

My view is that the later model is better. In practice the service must 
already have means for finding and connecting users, and perhaps present 
presence info. I think what type of communication they want should be 
sorted using these means.

In other words I think the PeerConnection API should be focused on 
setting up communication already agreed on.
>
>
> Accept m=audio, reject m=video
>
>
>>
>>
>> A third way, a bit uglier, would be that the user that would like to receive only audio only tells the local application only. The received stream would initially contain both audio and video, but only the audio would be rendered (since the app knows the user's preference). Using the media re-negotiation mechanism the video would over time be downscaled to a very low bitrate since it is not being rendered.
>>
>> Stefan
>>
>
> Shudder...  Why in this case would you not re-negotiate (offer/answer) to remove the
> video stream?  I assume it's because you think there's no way to negotiate it.
I'm just trying to exhaust the list of options with the current API. My 
preferred model is to agree beforehand as outlined above.

...and I just realized a fourth way (which I consider also a bit dirty): 
The SDPs are in the current incarnation of the API handled by the 
application. There is nothing stopping the the application from 
modifying them, so it would this way be quite simple for the application 
at the receiving end to refuse receiving e.g. the video component by 
modifying the SDP.

Bottom line: I think the requirement should be there (and will put it 
into next version of the req spec if there people doesn't object), but 
I'm still unconvinced that it is solved at the API level.
>
>

Received on Wednesday, 24 August 2011 08:23:18 UTC