Webrtc-pc: Simulcast makes no sense for audio.

[jan-ivar]

setParameters() (and JSPEP) appear kind-agnostic when it comes to allowing multiple encodings.

We should probably limit multiple encodings to video.

I see two options:

1. TypeError on sendEncodings.length > 0 in addTransceiver for audio, or
2. TypeError on sendEncodings.length > 1 in addTransceiver for audio.

The first option seems the simplest. The second may add some convenience but would let rid be set.

Also, we might want to ignore active, and remove active and priority from getParameters().

[jan-ivar]

We need to nail down what this API must support today so that we can test it. E.g. if someone calls:

pc.addTransceiver("audio", {sendEncodings: [{rid: 'f'}, {rid: 'h', codecPayloadType: 1}]});

browser vendors need to know what to do. I think we want all browsers to do the same thing.

[juberti]

I don't think simulcast is nonsensical for audio. Consider a high-bitrate and a low-bitrate encoding of the same audio source, wouldn't this make sense for the same reasons as video simulcast?

[aboba]

Consensus from the April VI was to develop a PR supporting a "best efforts" approach:

a. Requesting more simulcast streams than are supported will not result in an error.
b. sender.getParameters will return the number of simulcast streams that can be supported.
c. If simulcast is not supported, 0 streams is returned (rather than 1, so that RID is not sent).

[alvestrand]

If we return 0 streams, we have nowhere to set the bandwidth, which seems like a wrong thing.
I think it is OK to say that if 1 stream is returned, simulcast is off and no RID is sent.

[aboba]

@alvestrand. Yes, if no simulcast is supported, would be better to say 1 stream is returned, simulcast is off and no RID is sent.