we have a FreePBX15 setup where there are in and out video call scenarios between SIP endpoints. In one case we noticed stripes on the video conference screen. H264 is the chosen video codec and opus is the chosen voice codec.
Sometimes it gets full frame following INFO messages but in the beginning of the video call, Freepbx does not forward SPS and PPS packets out although it receives them.
Namely;
A => Video Conference device
B => PJSUA Client - connected to some other systems.
FreePBX version: FPBX-15.0.17.67(16.17.0)
A calls B, freepbx in between. B sends SPS/PPS packets in the beginning and freepbx does not fwd them to A, again when A sends SPS/PPS packets to freepbx, they are not fwded to B neither. So in both directions Freepbx does not let SPS/PPS packets transfered. Some conference devices cover this situation but some does not and we see occasional stripes on the video conference side.
Is there a setting in freepbx (chan_sip and/or chan_pjsip) managing this behaviour?
B is using method C from the RFC, but doing so over an unreliable transport (which is listed as a SHOULD NOT). If forced to do that it should be re-transmitting the parameter sets, because it should be assuming they could be lost.
From the packet timing, it looks to me as though B doesn’t start sending until it receives the ACK. If Asterisk hasn’t already answered, it may well do the same on the A side. in which case you can expect some (worst case about 30 seconds worth) to be dropped.
It’s also possible that A is using late offer SDP, in which case it is not physically possible to send the media on to A until its ACK is received.
Has A already been answered? If not, try setting the Force Answer option for the inbound route.
Force Answer is only normally for FreePBX trunks, not FreePBX extensions. You may have to use a hook to do the answer if A is considered an extension.
The ss below depicts the A => B flow where capture is taken before freepbx and the packets there are never forwarded to B side. However after many seconds/minutes and h264 packets later freepbx send some sps/pps packets after number of INFO messages.:
One thing you should note is that Asterisk knows essentially nothing about H.264; it will simply pass through the RTP packet for packet. As such, it will not recognize preference sets, and will not take any special steps to preserve them.
More precisely, it seems to understand how to parse preferences from the SDP and work out compatible choices but doesn’t know how to do anything, in detail, with the RTP, and probably dosn’t understand what the settings actually mean. It really requires you to either use standard profiles, or use methods A or B.
