Re: A proposal for how we would use the SDP that comes out of the MMUSIC interm

On Fri, Oct 9, 2015 at 12:33 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Peter Thatcher said:
>
> "As for what conferencing services want, the one I'm very familiar with
> wants a resolution scale.  So at least the desire for a fixed resolution
> isn't universal.
>
> And, as I already mentioned, services that do want a fixed resolution can
> send a fixed resolution from the JS via track controls.​​"
>
> [BA]  The one I'm familiar with would also prefer resolution scale,
> because it enables a wide range of scenarios while minimizing API
> complexity.
>
> Attempting to specify resolutions in both the encoder as well as in track
> controls is very likely to result in conflicts and complex corner
> conditions.
>
> AFAICT, it is quite possible to implement the important use cases without
> that.
>
> Peter also said:
>
> ​"I would point out, though, that the conference server really doesn't
> need to know anything about the RSIDs.  It already knows the sizes of the
> layers from the media itself and can just use that to choose what to
> forward.  ​It just needs the RSIDs to know which FEC or RTX stream goes
> with which layer."
>
> [BA] Is there a need to include an RSID attribute within Rtx or FEC
> parameters, rather than just the SSID?


​What's SSID?​

​  Did you mean SSRC?

And I think the answer is "no", we don't need to include the RSID in the
RTX and FEC parameters.  RSID is the RTP Source Stream ID.  "RTP Source
Stream" in the RTP taxonomy is the stream the RTX and FEC streams refer
to.  We don't need an ID from the RTX and FEC RTP streams.