W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

RE: sendonly streams in the offer

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 6 Apr 2013 04:50:47 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C296226@ESESSMB208.ericsson.se>
On 06 April 2013 12:18 AM Martin Thomson [martin.thomson@gmail.com] wrote
> On 4 April 2013 22:10, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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 think of a couple of reasons offhand.  An application might have
> constraints on how it uses the available display area.  Alternatively,
> an application that provides a relay might find this to be relevant.
> (In combination with bandwidth constraints, of course).

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.

I'd say that in 99% of the cases, it will be the same app in both ends, and how this kind of info is exchanged is completely up to the app author. For the remaining 1% of the cases, the app authors need to agree on how they exchange this info (if needed; I think most apps will only have one video track in each direction).

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

Received on Saturday, 6 April 2013 04:51:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC