W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2017

[webrtc-pc] Limiting number of RTCRtpTransceivers

From: Mark Roberts via GitHub <sysbot+gh@w3.org>
Date: Mon, 24 Jul 2017 22:30:02 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-245228482-1500935399-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC