[webrtc-pc] Limiting number of RTCRtpTransceivers

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

== Limiting number of RTCRtpTransceivers ==
Hi,

I have a few questions. As far as I can tell,

* In certain cases, when we call `addTransceiver` and `stop` over the course of a few rounds of negotiation, JSEP says we can recycle m= sections. This is nice because we don't necessarily need to keep adding m= sections to our SDP. ([Example 1](https://gist.github.com/markandrus/c970eeaf37c5b26cc8c7d7b4973cdc2a))
* However, we cannot recycle or remove RTCRtpTransceivers—these keep accumulating in the RTCPeerConnection's set of transceivers. The only time an RTCRtpTransceiver can be removed from the set of transceivers is during [rollback](http://w3c.github.io/webrtc-pc/#set-the-rtcsessionsessiondescription).
* The cases where we can reuse an RTCRtpSender are limited, too. If an application uses `addTrack` and `removeTrack` exclusively (no `replaceTrack`), the number of RTCRtpTransceivers will grow with each call to `addTrack`. We can only reuse a sender that "[has never been used to send.](http://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-addtrack)" ([Example 2](https://gist.github.com/markandrus/7761495b9af1a319e3ddba1f44fe0e7e))

If my understanding is correct, then I would like to know,

* Is there a limit on the number of RTCRtpTransceivers an application can create? Could an application create too many? If so, what happens?
* Can we remove stopped RTCRtpTransceivers from the RTCPeerConnection's set of transceivers?
* Are there more cases where an RTCRtpSender can safely be reused?

Thanks,
Mark

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

Received on Monday, 24 July 2017 22:30:04 UTC