Re: sendonly streams in the offer

This is starting to delve into the realm that CLUE occupies.

In clue we are ultimately still using SDP mechanisms that are focused on 
advertising what you can receive, but we layer a separate negotiation on 
top of that concerned with exchanging detailed info about media that 
*could* be sent, and receivers then selecting what they want to be sent 
from that menu.

 Thanks,
 Paul

On 4/5/13 1:10 PM, Stefan Håkansson LK wrote:
>
> 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 19:52:10 UTC