No incoming video for Firefox in custom MCU scenario

[Lorenzo Miniero]

Hi all, 

first of all, sorry for posting this here: I tried posting on the mozilla.dev.media group, but almost three weeks have passed without a reply, so I guess I won't get any indication there on what may be going wrong. Since I assume most of you will be doing tests with both Chrome and Firefox, I hope I'll get luckier here!

I'm encountering a few issues in getting Firefox to work with my Janus gateway in a couple of scenarios. Specifically, when I setup a video MCU, Chrome users get video from everybody participating (other Chrome and Firefox users), while Firefox users only get it from other Firefox users.

Just as a heads-up on how the video MCU scenario works, each user has N+1 peer connections set up with the gateway: one is sendonly and used to send the peer's media to the gateway, and then there are N recvonly streams where the peer can receive each other individual participants contributions instead. As I anticipated, the outgoing stream in principle seems to be working, as both Chrome and Firefox instances are able to playout what Firefox is sending, so no problem there apparently. 

I should also point out that other scenarios handled by my gateway work fine with Firefox instead, meaning that DTLS, ICE, SRTP and so on should not be the issue. For instance, the simple video call scenario works fine instead, with either Chrome or Firefox being the caller or the callee, which means that it's not a problem with who is generating the call and who is receiving it.

That said, looking at the about:webrtc logs, I can see that for the PeerConnections that don't work I'm getting statistics that look like these: 

   RTP statistics 
   inbound_rtp_audio_1 
   A/V sync: 0 ms Jitter-buffer delay: 60 ms 
   Local: 13:09:35 GMT+0200 (CEST) inboundrtp SSRC: 12345 Received: 670 packets (28.79 Kb) Lost: 0 Jitter: 0.003 
   inbound_rtp_video_2 
   Local: 13:09:35 GMT+0200 (CEST) inboundrtp SSRC: 0 Received: 758 packets (502.82 Kb) Lost: undefined Jitter: undefined 

Both the ICE and DTLS steps are correctly completed. I guess that the 0 SSRC is the root cause of the issue there. For some reason, Firefox has no view of the SSRC the gateway is using for video. The SSRC is there in the SDP, and is correctly set in both RTP and RTCP packets, and frames are definitely being received, as the sample log above seems to confirm. As a related issue, Firefox ignores FIR requests too, I guess for the same reason. What's weird is that the receiving part works fine if the related sender is another Firefox instance (even though it may appear after a while as FIR messages don't work).

Investigating the logs I also found some lines like this:

    -260211904[f751b500]: [Socket Thread|WebrtcVideoSessionConduit] VideoConduit.cpp:959: Error: ReceivedRTCPPacket when not receiving

that apparently indicate that Firefox is discarding RTCP packets for the sendonly PeerConnection. Anyway, I don't think that's the cause of the issue, otherwise Firefox clients wouldn't be able to get the video coming from other Firefox participants either.


Could you help me understand what I may be doing wrong? As far as you know, is there any specific step that may be missing that Firefox needs to have a valid SSRC? You can test the scenario yourself using the public demo page we have here: 

   http://janus.conf.meetecho.com/videomcutest.html 

or, if you prefer (it's open source, after all), installing the gateway on one of your machines and test locally.

Let me know if there's any other info you may need of me to help me finally tackle this issue. 

Thanks! 
Lorenzo

[bryand...@gmail.com]

Hi Lorenzo,

I feel your pain about the dev-media list being mostly unresponsive.  

I have a setup in my MCU similar to what you describe, and it works well on both Chrome and FF.  Some thoughts...

You don't mention if your MCU aggregates RTCP.  The sender will not know about the various receiver SSRCs.  The sender knows only about the MCU as the receiver.  So, any RTCP (PLI/FIR) should come from the MCU with the MCU's ssrc.  Is that your setup? 

You also don't mention ports.  Is each fanout on its own port or a shared port?  If your single stream case works, and the others do not, I wonder if you are maybe using the same ip:port on the server to send multiple streams to the same receiver.  

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

Hi Bryan,

good thing people are responsive here instead, thanks for your reply :-)

The gateway does not aggregate RTCP packets but forwards them selectively, and fixes the SSRCs in the packets before forwarding them, to take what you mentioned in the account. That said, I've tried several combinations (don't forward RTCP, forward just from the publisher to the listener and/or viceversa) with respect to RTCP behaviour, but it didn't seem to help.

Ports shouldn't be an issue either, as each time you attach to a new feed (a publisher) in the MCU case you're actually doing a separate negotiation for a new PeerConnection, that is separate from the others. The packets are then reflected to the right ones.

My guess is that it is indeed something related to RTCP, though. In fact, while at first I suspected the recvonly nature of the subscriber feeds being the cause, the same kind of scenario works fine in the Streaming demo (where the plugin sends a sendonly offer to the browser, exactly as it happens for subscribers in the MCU).

Lorenzo

[bryand...@gmail.com]

Even though the sender is sendonly and receivers recvonly, my SDP offer is sendrecv, and I leave it up to the implementation to figure out that receivers have no local stream attached and do the right thing.  There used to be bugs around RTCP processing when you did not specify sendrecv, but I have not kept up on that issue.

fixing up an RR's SSRC seems error prone due to sequence numbers from different receivers overlapping.  What I settled on was having the MCU re-issue PLIs and NACKS in response to a receiver's (unfilled) request, at a max rate.

HTH

[Lorenzo Miniero]

But that would help solve the issue if the problem was with the senders, right? In my case, sending apparently is not the issue, as both Chrome and Firefox are able to send alright. Receivers, instead, do have problems on Firefox: in that case, dealing with RTCP should be even easier, as you don't have to aggregate anything, but you can just forward the publisher's RTCP to the receiver and it should work as if it were a 1-1 call (I don't mess with sequence numbers and timestamps).

Lorenzo

[Lorenzo Miniero]

Just FYI, I solved the issue, which was much more trivial than I thought... no issue at all with RTCP, sendonly/recvonly and the like, simply the fact that, for publishers (and because I was lazy! :-) ), when replying to them I mirrored back their SDP, before adapting it for all subscribers interested to their feed. This obviously resulted in Chrome making use of stuff Firefox doesn't support for video (e.g., RED), which explained why I was getting the issue. Fixing the SDP involved for publishers and listeners did the trick and now it works perfectly.

Lorenzo

[bryand...@gmail.com]

Are you actually decoding RED/ULPFEC and resending plain VP8, or are you going to drop RED/FEC from the offer?

--

[Lorenzo Miniero]

The video MCU just reflects what it receives, so, since Chrome was actually sending RED/FEC (as it thought it to be supported), all its subscribers, including Firefox ones, would get those. Firefox dumped them since they're not supported, while it correctly played the audio instead.

Not sure why the SSRC was always 0 in the about:webrtc page, though, as the RTP header should be there anyway.

Anyway, that's settled now :-)

[Lorenzo Miniero]

To clarify, I'm just reflecting so no decoding, RED/FEC is dropped from the offer.

Lorenzo