Bridge Configuration In Asterisk 13

Home » Asterisk Users » Bridge Configuration In Asterisk 13
Asterisk Users 1 Comment

Hi Everyone.

I was referred here by malcolmd of the Asterisk forums. What follows is a copy of this question: http://forums.asterisk.org/viewtopic.php?f=1&t=92007?

I’ve recently upgraded from Asterisk 11 to Asterisk 13.

Most of it went smoothly thanks to the documentation detailing how to upgrade to 12 and then how to upgrade to 13.

The only thing that didn’t work correctly was Music On Hold. Eventually I tracked this down to using bridge_softmix instead of bridge_simple.

What I’m asking is, does anyone have any explanation as to why MOH would not work with bridge_softmix? Asterisk 11 had been working for at least a year with bridge_softmix and the MOH was fine. With the same configuration (almost) Asterisk 13 insists I use bridge_simple otherwise I see no messages on the CLI about hold music starting or stopping. Unloading bridge_softmix and then loading bridge_simple fixes the issue.

Also does anyone have any documentation on what bridges I should be using? I can’t seem to find anything in the upgrade documentation that says “MOH will no longer work in softmix, you should use simple”. This has me concerned that I’ve done something wrong elsewhere in my config that is causing softmix to not work correctly.?

Regards, Patrick.

One thought on - Bridge Configuration In Asterisk 13

  • The bridging technology bridge_softmix is only used by app_confbridge in Asterisk v11. Nothing else in v11 uses the bridging framework. Unless you were using app_confbridge, you were not using bridge_softmix in v11.

    The various bridging technology modules in v12 and later are for different scenarios. The bridging framework is smart enough to pick the best bridging technology available for the situation. If the situation changes during a call, the bridging framework can change the bridge technology to support the new situation.

    * bridge_simple is for normal two party communication.

    * bridge_native_rtp is a special case of two party bridge were both parties use RTP for media exchange. The native technology allows for direct media.

    * bridge_softmix is for multi-party bridges where you can have 1 to n users communicating in a conference. As you found out, bridge_softmix can be used as a fallback if bridge_simple is not available because it allows two party communication.

    * bridge_holding is a parking bridge technology to hold calls for later connection. Parties in a holding bridge cannot communicate with each other.

    * bridge_builtin_features and bridge_builtin_interval_feature provide functionality used by features.conf. These two modules are actually not bridging technologies but support code for features.conf functionality.

    You usually need to install all of the bridging technologies.

    Richard