Re: sendonly streams in the offer

On 4/9/13 12:38 AM, Martin Thomson wrote:
> 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.

We assume SDP as the format of things exchanged between the UAs to set 
up the "connections" and the media flowing on top of them.

The more we add, the more we need to specify in detail, the more we need 
to test and verify. I seriously believe that we should put as little as 
possible into that SDP. Naturally everything that is related to the RTP 
streams to be set up, all connection info must be there, but things that 
can be resolved by other means should be pushed out IMO.

>
>>>> 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.

So what you are basically talking about is bandwidth use, and that is 
something that to me is very related to the connections and to the media 
streams, so that is something that naturally fits in the SDP.

>

Received on Tuesday, 9 April 2013 11:50:03 UTC