Local Channel Multistream and Re-Negotiation Support

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 of Asterisk to gain stream support is… Local channels!

For those who may be unfamiliar or need a refresher on what Local channels are they are essentially the dialplan but in the form of a channel. You can call them like a channel, you can transfer them, you can be bridged to them, you can do lots of things. Local channels are extremely useful. They work by creating two channels to ensure proper Asterisk threading is adhered to. One channel executes dialplan while the other is free to do other things. Internally within the implementation a forwarder exists such that if you send media to one of the Local channels it appears on the other side. If you’ve never used Local channels you are very much missing out on a very useful part of Asterisk.

When we initially implemented stream support we did not add support to Local channels for it as it was not needed. That time is over though! Local channels as of Asterisk 16.12.0 and 17.6.0 now support streams. What does this mean though?

Before this change was done given a scenario where you have a PJSIP channel calling a Local channel that is then placed into a ConfBridge it was not possible for SFU functionality to work. This was because when the Local channel was told to re-negotiate to add other participant streams it would ignore the request. As a result the PJSIP channel would not be told to re-negotiate and you would not see the other lovely people in your conference.

After this change the Local channel when told to re-negotiate will now accept the re-negotiation request and update its own list of streams. It will then notify the other Local channel that the list of streams has changed, resulting in whatever may be handling the channel noticing and taking action. If bridged to another channel (such as our PJSIP channel from before) that channel is itself told to re-negotiate thus adding in the streams. When all is said and done the streams are mapped and media flows as you’d expect.

A good example of something you can do with this addition is originate using AMI to a Local channel to do extra work and sending the call to a video conference. Previously this would not have been possible.

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?