Re: sendonly streams in the offer

On 5 April 2013 21:50, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> For sure there are reasons when this information is useful, but I don't think we should use the SDP to convey it. The more we stuff into the SDP the more difficult it will be to finalise this work.

Ahh, the very essence of comment 22 :)

Sadly, that philosophy was designated heretical.  I believe that the
tacit requirement was that stuff would "just work" based on the SDP.

>>> 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.
>>
>> That's why this actually becomes more important.  It's an escape valve
>> for applications who can't deal with that complexity when they find
>> that the UA can't either.
>
> Here seems to be something that I miss in my reasoning, but I do not follow completely. Could you elaborate?

The key is the receiver.  If the receiver is unable to effectively
communicate a complete matrix of its constraints and capabilities such
that it can be effectively combined with the UAs constraints and
capabilities, then it has to have some sort of safety so that it
doesn't get more than it can handle.

For example, my app provides relays with certain bandwidth allocations
for clients, but if clients negotiate to their full capacity, that can
overuse my relays.  That's bad, so I need ways to curtail resource
usage.  That's the sort of escape valve I was talking about.

Received on Monday, 8 April 2013 22:39:01 UTC