[webrtc-pc] Do simulcast offers need to contain RIDs of all streams in both directions? (#2053)

amithilbuch has just created a new issue for https://github.com/w3c/webrtc-pc:

== Do simulcast offers need to contain RIDs of all streams in both directions? ==
Spec seems to indicate that an offer to send simulcast needs to also indicate the RID of the single stream it will receive:
`a=simulcast:send 1;2;3 recv 4`
likewise if the offer is generated by the SFU
`a=simulcast:recv 1;2;3 send 4`

This seems to indicate that all the RIDs are known well in advance.
There does not seem to be any advantage to this except adding restrictions to the RIDs.
Analyzing both cases:
1. Simulcast sender is offering - in such a case, there should only be a single receive RID and there is no benefit in adding any restrictions as they could be directly negotiated in the media section.
2. SFU is offering - in such a case, it makes sense for the receive RIDs to be specified explicitly as there are multiple layers and the information about the layers needs to be specified.

Another drawback to this is that it is somewhat inconsistent with current negotiation (of SSRCs) which is asymmetrical (Offer does not contain SSRCs for receive streams). In fact, SSRCs, or RIDs are not required in the incoming stream from the SFU as MID should be sufficient for demuxing.

Furthermore, what should be done in subsequent offers if a RID was not signaled but was discovered in the header.

I have noticed that Firefox examples do not contain both directions.
This should be further clarified in the spec.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2053 using your GitHub account

Received on Saturday, 12 January 2019 01:11:08 UTC