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.
Inside the Asterisk
When stream support was initially added to Asterisk we did it in the most backwards compatible way possible to ensure that we did not have to modify the entirety of Asterisk. This has allowed us to gradually improve parts of Asterisk as we’ve expanded our stream and video support. To that end the next part
A couple of weeks ago, Dan Jenkins kindly wrote a guest blog post about Dana — an up-and-coming open source project which helps to highlight some of the great video-conferencing capabilities in Asterisk. In this blog post, I’d like to expand on that, and show you how to get a simple video-conferencing solution up and
When stream support was added to Asterisk it was initially done with the focus being for SFU with a single video stream from each participant with the call starting out with video. This is a use case which is useful for a lot of people and has worked well. Coming soon, however, is the ability
In “Enrich Your Conference App with Asterisk Enhanced Messaging – Part 1” I demonstrated how you could include chat or other messaging features in your conference app. In Part 2, I’ll show you how to include information about the conference bridge itself and the participants. What data is available? If you’re familiar with the AMI
In the past, we’ve had a few blog posts talking about specific parts of new WebRTC work that has been done in Asterisk; but, with the release of Asterisk 16, we need to talk about the real-life impact of this work under poorly-performing networks and the resulting video experience. Before we start, let’s dive into
Introduction Packet loss can be an annoying problem when dealing with real time communication, especially when dealing with video. It’s very noticeable when the screen freezes for multiple seconds, then the footage resumes with everything in a completely different position than it was originally. We’ve all seen this before. Packet loss is inevitable, but it