[webrtc-rtptransport] RTCRtpSender.replaceSendStreams() and simulcast issues (#64)

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

== RTCRtpSender.replaceSendStreams() and simulcast issues ==
Currently, the API document lists:
```
partial interface RTCRtpSender {
  Promise<sequence<RTCRtpSendStream>> replaceSendStreams();
}
```

How is this supposed to work with more advanced simulcast usage?
When we have rollbacks and renegotations that can change the simulcast envelope, the number of rids is going to vary, and since our `RTCRtpSendStream` objects are tied to a single mid/rid pair, this will be difficult to work properly. What would happen to a send stream if its rid has been negotiated away?

We could add events to get notified when we have renegotiated to be able to get newer `RTCRtpSendStream` objects, but I think that's going to be very clunky, especially if we want to transfer them to DedicatedWorkers.

An alternative would be to have a single `RTCRtpSendStream` object per sender (or mid) and each `sendRtp()` call will have the `rid` as a parameter (which could be required if multiple simulcast layers have been negotiated), possibly in the `RTCRtpPacketInit` dictionary.

`rid` would still be validated against the list of known values that have been negotiated, and we shouldn't be losing in capabilities.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 August 2024 12:20:56 UTC