We have been testing the JVB 2 and H264 isn’t working for us. When a client adds an H264 stream, the track content never shows up on the remote side (the track is muted). And we see this in the JVB logs.
WARNING: Dropping an RTP packet, because egress was unable to find an associated encoding. rtpPacket=RtpPacket: PT=107, Ssrc=584900224, SeqNum=2269, M=false, X=true, Ts=1937318498. Are there known issues with H264 on the new JVB or any ideas of why it wouldn’t be working?
We are currently using the jitsi-videobridge2 2.1.137-g07c5cc83 debian package with a slightly modified jicofo based on the latest stable tag (jicofo 508). The only changes to jicofo are a couple patches to the reservation api (here and here). We have a custom client and H264 was working on our current production version of the bridge (which is about a year old).
A few other things we’ve noticed in JVB 2/jicofo:
- The JVB doesn’t send a lastNEndpointsChange message on transport connected. There is a TODO in the JVB code for this
- The new JVB won’t open a data channel by default or if you set the conference openSctp property (we updated our client to account for this, but this feels like a breaking change especially since jicofo still has the openSctp property but it is ignored)
- Jicofo throws an ArrayIndexOutOfBoundsException if the client doesn’t send its feature list and jicofo falls back the default feature list (we discovered because we had a test that wasn’t sending the feature list in response to disco info, not important as the test was fixed to have the client send the features but mostly an FYI)