Bugzilla

(In reply to Luis Rivas from comment #7)
> Absolutely, we can keep that site as is so you can use it for validations. While we considered workarounds for Twilio Video, supporting the Mozilla team in addressing the issue seems best. A quick fix might cause problems with other use cases and future Firefox versions, as it's hard to pinpoint the exact issue.

Thank you Luis. Please note we have confirmed three different fixes at different levels all address the issue of not receiving video. Not all are up yet.

During our investigation on https://networktest.twilio.com we found there are three offer/answer exchanges taking place. We don't think that's relevant but haven't finished a minimal test case yet.

The final local description for Firefox, an answer, contains two video m-lines, one inactive and one recvonly. This is relevant and triggers the bug. In particular, presence of the inactive m-line with the same payload type as in the video packets sent to us (and in the active m-line) causes confusion down the line in our code. For working out a workaround, you could focus either on the inactive m-line or its payload types.

(In reply to Luis Rivas from comment #7)
> Absolutely, we can keep that site as is so you can use it for validations. While we considered workarounds for Twilio Video, supporting the Mozilla team in addressing the issue seems best. A quick fix might cause problems with other use cases and future Firefox versions, as it's hard to pinpoint the exact issue.

Thank you Luis. Please note we have confirmed three different fixes at different levels all address the issue of not receiving video. Not all are up yet.

During our investigation on https://networktest.twilio.com we found there are three offer/answer exchanges taking place. We don't think that's relevant but haven't finished a minimal test case yet.

The final local description for Firefox, an answer, contains two video m-lines, one inactive and one recvonly. This is relevant and triggers the bug. In particular, presence of the inactive m-line with the same payload type as in the video packets sent to us (and in the active m-line), and absence of the MID RTP header extension in both m-lines (and packets) causes confusion down the line in our code. For working out a workaround, you could focus either on the inactive m-line, its payload types, or MID.

**edit May 14**: *added the bit on MID*

(In reply to Luis Rivas from comment #7)
> Absolutely, we can keep that site as is so you can use it for validations. While we considered workarounds for Twilio Video, supporting the Mozilla team in addressing the issue seems best. A quick fix might cause problems with other use cases and future Firefox versions, as it's hard to pinpoint the exact issue.

Thank you Luis. Please note we have confirmed three different fixes at different levels all address the issue of not receiving video. Not all are up yet.

During our investigation on https://networktest.twilio.com we found there are three offer/answer exchanges taking place. We don't think that's relevant but haven't finished a minimal test case yet.

The final local description for Firefox, an answer, contains two video m-lines, one inactive and one recvonly. This is relevant and triggers the bug. A number of things have to hold for this bug to trigger:
- a video m-section A must have been the only m-section, and active with a recv direction, when negotiated
- m-section A may at no point have had an `a=ssrc` line
- a renegotiation must happen where A is inactive and another video m-section B is active with a recv direction, and with the same payload types that A was configured for when active
- m-sections A and B must be combined with BUNDLE
- no MID RTP header extension, at least for m-section A

If all this holds and packets destined for m-section B are received, our code gets confused, routes them to A instead (which is inactive, so the packets in the end are just ignored) and B gets reconfigured internally for some other recv ssrc that we generate on the fly

**edit May 14**: *added the bit on MID*
**edit May 15**: *rewritten with the bits on a=ssrc lines and renegotiation*