Limiting number of RTCRtpTransceivers

[markandrus]

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)
• 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.
• 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." (Example 2)

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

[stefhak]

I think this is a more generic question. In 'Is there a limit on the number of RTCRtpTransceivers an application can create?' you could replace 'RTCRtpTransceivers' with e.g. RTCPeerConnections, or WebSockets, or MediaStreams, etc. and I assume there is a limit (depending on browser, system, HW etc.), but AFAIK no way to determine what the limit is.

[markandrus]

@stefhak yeah, my first question is fairly generic/obvious. I too assume there is a limit. I'm actually interested in the follow-on questions.

Although JSEP specifies that we can reuse a stopped RTCRtpTransceiver's m= section, there isn't a similar behavior at the WebRTC layer for "freeing" stopped RTCRtpTransceivers. AFAICT, if I have some long-lived application calling addTransceiver/stop or addTrack/removeTrack I will just keep accumulating RTCRtpTransceivers at the WebRTC layer, even if JSEP is keeping my m= sections tidy. This feels especially strange to me if the application follows each call to addTrack with removeTrack, since—reading the APIs alone—you might not suspect they leak a resource (the RTCRtpTransceiver).

Can this or should this be changed? E.g., by removing stopped RTCRtpTransceivers from the RTCPeerConnection's set of transceivers? By reusing RTCRtpSenders in more scenarios?

[stefhak]

@markandrus got that!
I would guess that a RTCRtpTransceiver does not cost much in terms of memory etc. but some implementers should comment.

[burnburn]

What about stats that need to remain for these objects?

[taylor-b]

I think it would be reasonable to say that when a transceiver is stopped, and its m= section is recycled for another transceiver (meaning it's "not associated" with an m= section any more), it gets removed from the set of transceivers, since it's not needed by JSEP's algorithms any more.

But Dan's point about stats is that we already have another problem about memory use increasing indefinitely. Stats for deleted objects are kept around forever:

The general rule is that stats objects, once created, exist for the lifetime of the PeerConnection that contains them, even when the underlying object they report on is stopped or deleted. This is important in order to report consistently on short-lived objects and to be able to report totals over the lifetime of a PeerConnection.

[aboba]

@stefhak Is this issue really for WebRTC-PC or for WebRTC-Stats?

[stefhak]

@aboba I think it is an Issue for webrtc-stats, I've opened w3c/webrtc-stats#235 and am closing this Issue.

[markandrus]

Hi,

Thanks for the discussion everyone. Good point on the stats, I had not considered it. However, should we close this issue so soon? I was interested in what @taylor-b mentioned:

I think it would be reasonable to say that when a transceiver is stopped, and its m= section is recycled for another transceiver (meaning it's "not associated" with an m= section any more), it gets removed from the set of transceivers, since it's not needed by JSEP's algorithms any more.

Is there any interest on this from implementors? Can we continue tracking this either here or in another issue? Speaking as a library author, I am still a little concerned with the potential for many RTCRtpTransceivers (although I had totally missed the stats issue).

Thanks,
Mark