- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 5 Apr 2013 07:10:35 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 04/04/2013 11:17 PM, Martin Thomson wrote: > On 4 April 2013 04:29, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com> wrote: >> Yes, in a sense it is suboptimal; but the difference is not that great (the >> now offer adding video could go out as soon as the answer to the audio only >> offer has been sent). And I guess we would force it on developers rather >> than users. >> >> That said, this is already solved for plan B (OfferToReceiveX). > The OfferToReceive* constraints and their implementation is orthogonal > to the choice of Plan (A or B). Unless we believe that there is no > need to limit the number of inbound streams, which is the only > available mode for Plan B in the absence of extensions like max-ssrc. I don't really see a need why the application would limit the number of inbound streams (e.g. by applying some setting on the PeerConnection). I can see a benefit of the receiving UA telling the sending UA how many streams it can handle, but that would depend on things like resolution, frame-rate, etc. and may not be that easy to express.
Received on Friday, 5 April 2013 05:11:01 UTC