I know from the ealier topics that these packets are expected for the disabled SDP sections. However, combined with the current solution of this issue , it creates quite a flow of packets in Firefox if many producers are created and closed: SDP is growing indefinitely since no sections are reused, an…

The issue you mentioned was already fixed over a year ago according to comments. Moreover, sections are reused since https://github.com/versatica/mediasoup-client/commit/c0da3089167440e53c57c87f8f235bcdd5f2bd8f was merged a few months ago. There must be something about the way you use the library …

In case of Firefox, sections are intentionally not reused. Take a look at the send method of the Firefox60 handler.

True, sorry. I think if there it is the best to find or report upstream Firefox issue on Bugzilla then.

It’s kind of complicated. Exactly what is the bug here? That issue #104, as far as I understand, was caused by the fact that mediasoup client is trying to ‘guess’ what is in the local offer received from the browser without even looking into it. The browser developers can always ask: “Why would you …

Well, at least m= reuse support would be nice to have, not sure if there is already ticket for it.

In this case m= reuse conflicts with the method of making an answer that matches the offer. I am not familiar in detail with the technology: the comment in the send method of the Firefox handler says that Firefox should reuse the closed media section, but fails. Is that really so? The client adds ne…

[image] snnz: the comment in the send method of the Firefox handler says that Firefox should reuse the closed media section, but fails. Is that really so? Well, yes. The comment says that because yes, Firefox doing that. Now, it seems that we (mediasoup team) are responsible fo a bug in Firef…

Well, I investigated a little what really happens there. It seems that Firefox does reuse the m= sections, but in its own way: it chooses not just first available closed section, but the section where the track kind matches the track kind in the new transceiver. And the RemoteSdp.getNextMediaSection…

[image] snnz: Well, I investigated a little what really happens there. It seems that Firefox does reuse the m= sections, but in its own way: it chooses not just first available closed section, but the section where the track kind matches the track kind in the new transceiver. Nice. This is so…

Yes, we assume that “closed m= section reusing” does not require same kind Doesn’t this mean skating on thin ice? To me, finding where the new transceiver has landed in the local offer appears to be a straightforward approach, I would have rather used it than relied on some guess about what brows…

Firefox and redundant Sender Extended Report packets

mediasoup libraries

atomic-tang (Andy) May 7, 2021, 3:23am 15

I posted this issue on the mediasoup-demo forum and it seems to be related to issue #104. When closing and creating video producers too frequently on Firefox when using simulcast (For me this happens on the 3rd attempt), stream layers aren’t produced or their scores drop to 0 where streams are consumed at the lowest resolution.

Topic		Replies	Views
The problem with Firefox when reuse mediaSection (maybe help someone) mediasoup libraries	1	76	April 15, 2026
mediasoup-client not working on Firefox mediasoup libraries	14	2428	November 30, 2019
Recent Firefox and mediasoup-client v2 mediasoup libraries	3	506	January 23, 2020
Failed to process the bundled m= section. mediasoup libraries	19	4102	September 2, 2019
Error: a=ssrc line with msid information not found mediasoup libraries	9	601	June 4, 2019

Firefox and redundant Sender Extended Report packets

Related topics