In the previous post, Josh introduced the forthcoming addition of streams to Asterisk. I’m going to piggyback on that to introduce a unified SDP API to Asterisk.
What’s the motivation behind these additions? In recent years, Asterisk has risen above its old branding as a PBX. Support for WebRTC, combined with a REST API, has made Asterisk into a multimedia communications platform. Even with these additions, there are fundamental limitations in the core of Asterisk that have prevented more advanced scenarios. The goal for the next versions of Asterisk is to improve video support.
In the long journey that is improved video support, you have to start by taking the first step. For us, that means recognizing targets for video support. The most compelling target for video is WebRTC. There are lots of WebRTC endpoints out there, and one thing they all have in common is they negotiate their sessions using SDP. In Asterisk right now, if a channel technology uses SDP, then that channel driver must perform its own SDP parsing and generation. That means that if we were to add new channel drivers, they all would have their own independent SDP code. That is a lot of repetition.
The solution to this is the SDP API. By providing media capabilities and a set of requested features, the API will parse, generate, and negotiate SDP. The SDP layer will also use SDP attributes in order to set up the underlying RTP sessions. This takes a lot of work out of channel drivers’ hands. Any new channel driver we add that uses SDP can leave the hard work in the hands of the API and automatically have all the features the API supports. This also leads to a more streamlined path for adding new SDP features.
Admittedly, stream support and an SDP API aren’t the sexiest additions we could be announcing. However, we feel like they’re the first steps towards being able to add fantastic new features in Asterisk. Stay tuned!