Video has been a continued theme of Asterisk for some years now. We put into place the foundation to allow us to do video better, and have over time taken advantage of this and advanced things further. I thought I would take a little bit of time to reflect back on what has been done.

Multiple Source Streams

When video conferencing support was initially added to Asterisk we only supported receiving a single video stream from a participant. This simplified the code and best fit the usage. As things progressed we received requests and feedback that allowing multiple source streams would be beneficial. Support for this was added to ConfBridge earlier this year, allowing any number of source video streams to come from a participant. Check out this blog post for further details.

Adding and Removing Video Mid-Call

A feature that Asterisk has never supported was allowing video to be added and removed mid-call. We always expected to set up calls initially with video, sometimes even if a calling party did not themselves have video resulting in a poor user experience. Thanks to the foundation that was put into place we now support this functionality across normal two party calls as well as video conferences. Check out this blog post for further details.

Local Channel Support

Local channels are frequently used to implement things in Asterisk by its users. Until this point they did not have support for multiple video streams or for re-negotiation. This has now been added allowing Local channels to be put in between a PJSIP channel and a video conference bridge without any issue. Check out this blog post for further details.

Improved Performance

While working on Local channel support a performance tweak was also done to the way that media flows through bridges. Prior to the change a channel would be given media and expected to wake up and either relay it or discard it. An improvement has been done to bridging to discard unnecessary media sooner resulting in the channel waking up less often and providing better performance.

Tweaked Packet Loss Behavior

During testing it was seen that in extreme packet loss scenarios our existing logic for handling it was not dynamic enough resulting in a poor experience. Both the buffer for packets that have been receiving and that have been sent will now grow to handle more packets in cases where there is extreme loss. The sending of NACK requests (these requests are used to request that the remote side re-send RTP packets) is also now more aggressive. After a substantial number of missing packets is detected we will send a NACK request. As the receive buffer continues to fill while we wait for any missing packets we will continue to send NACK requests at certain thresholds.

I hope this recap of what has been done with video shines some light on things you may not have known!