(I'll point out up front that we're not using xmpp/jicofo, this involves
our own signaling and the REST api to the bridge)
We were recently doing some testing with video mute where we would destroy
the local camera stream and update the sdp to 'recvonly' for the video
mline. This had the unfortunate side-effect of freezing the *remote* incoming
video and we had no idea why. After digging deeper, we found that when
this new description was sent up to our signaling, we updated the bridge
appropriately (or, we *thought* appropriately). This included changing the
video channel for this client to "recvonly". This direction change caused
the bridge to stop forwarding video to the muted client. I changed this to
'invert' at the bridge level (client recvonly->bridge sendonly, etc.) and
that worked, and after thinking about it, that does make sense, although
the channel allocation on the bridge makes it feel more like a 'proxy' for
the client rather than an endpoint that happens to forward to the client,
but just semantics I suppose.
When I say it "worked" that was mainly the case, but it freezes quickly due
to NACK/PLI seem to cease working after doing this. I suspect that this
may have something to do with the RTCP sender SSRC--I've seen chrome having
issues with this before (issues with RTCP feedback from recvonly streams).
I'll take a look at chrome logs on the receiving side, but has anyone seen
this issue before?