Skip to end of metadata
Go to start of metadata


Asterisk, since its early days, has offered a conferencing application called MeetMe ( MeetMe provides DAHDI-mixed software-based bridges for multi-party audio conferencing. MeetMe is used by nearly all Asterisk implementations - small office, call center, large office, feature-server, third-party application, etc. It has been extremely successful as an audio bridge.

Over time, several significant limitations of MeetMe have been encountered by its users. Among these are two of distinction: MeetMe requires DAHDI for mixing, and is thus limited to 8kHz (PSTN) audio sampling rates; and MeetMe is delivered in a fairly static form, it does not provide extensive configuration options.

To address these limitations, a new conferencing application, based upon the ConfBridge application introduced in Asterisk 1.6.0, is now available with Asterisk 10. This new ConfBridge application replaces the older ConfBridge application. It is not intended to be a direct replacement for MeetMe, it will not provide feature parity with the MeetMe application. Instead, the new ConfBridge application delivers a completely redesigned set of functionality that most users will find more than sufficient, and in many ways better, for their conferencing needs.

On This Page

ConfBridge Concepts

ConfBridge provides four internal concepts:

  1. Conference Number
  2. Bridge Profile
  3. User Profile
  4. Conference Menu

A Conference Number is a numerical representation for an instance of the bridge. Callers joined to the same conference number will be in the same conference bridge; they're connected. Callers joined to different conference numbers are not in the same conference bridge; they're separated. Conference Numbers are assigned in the dialplan. Unlike MeetMe, they're not pre-reserved.

A Bridge Profile is a named set of options that control the behavior of a particular conference bridge. Each bridge must have its own profile. A single bridge cannot have more than one Bridge Profile.

A User Profile is a named set of options that control the user's experience as a member of a particular bridge. Each user participating in a bridge can have their own individual User Profile.

A Conference Menu is a named set of options that are provided to a user when they present DTMF keys while connected to the bridge. Each user participating in a bridge can have their own individual Conference Menu.

ConfBridge Application Syntax

The ConfBridge application syntax and usage can be found at Asterisk 13 Application_ConfBridge

ConfBridge Application Examples

Example 1
In this example, callers will be joined to conference number 1234, using the default Bridge Profile, the default User Profile, and no Conference Menu.

exten => 1,1,Answer()
exten => 1,n,ConfBridge(1234)

Example 2
In this example, callers will be joined to conference number 1234, with the default Bridge Profile, a User Profile called "1234_participants" and a Conference Menu called "1234_menu."

exten => 1,1,Answer()
exten => 1,n,ConfBridge(1234,,1234_participants,1234_menu)

Usage Notes, FAQ and Other

There are many points to consider when using the new ConfBridge appliation. Some will be examined here.

Video Conferencing

It is imperative that a video conference not have participants using disparate video codecs or encoding profiles. Everyone must use the same codec and profile. Otherwise, the video sessions won't work - you'll likely experience frozen video as the conference switches from one video stream using a codec your client has negotiated, to a video stream using a codec your client hasn't negotiated or doesn't support.

Video Endpoints

ConfBridge has been tested against a number of video-capable SIP endpoints. Success, and your mileage will vary.

Endpoints that work:

  • Jitsi - Jitsi works well for both H.264 and H.263+1998 video calling on Mac, Linux and Windows machines. Currently, Jitsi seems to be the best-working, free, H.264-capable SIP video client.
  • Linphone - Linphone works well for H.263+1998 and H.263 video calling on Linux - the Mac port and mobile ports do not support video. Currently, Linphone seems to be the best-working, free, H.263-capable SIP video client, when Jitsi or H.263+1998 aren't an option.
  • Empathy - Empathy works for H.264 calling, but is amazingly difficult to configure (why one has to make two SIP accounts just to make a SIP call is a mystery).
  • Lifesize - The Lifesize client supports H.264 and runs on Windows only. It works very well, but it isn't free.
  • Polycom VVX 1500 - The Polycom VVX 1500 works well for H.264 calling. If you're connecting it to Jitsi, you may have to configure Jitsi to use the Baseline H.264 profile instead of the Main profile.

Endpoints that don't or weren't tested:

  • Xlite - Xlite works in some cases, but also seems to crash, regardless of operating system, at odd times. In other cases, Xlite isn't able to decode video from clients.
  • Ekiga - Ekiga wasn't tested, because our test camera wasn't supported by the client. The same camera was supported by other soft clients.
  • SIPDroid - SIPDroid doesn't seem to work.
  • OfficeSIP Messenger - OfficeSIP Messenger didn't seem capable of performing a SIP registration. On this basis alone, no one should recommend its use.

Mixing Interval

The mixing interval for a conference is defined in its Bridge Profile. The allowable options are 10, 20, 40, and 80, all in milliseconds. Usage of 80ms mixing intervals is only supported for conferences that are sampled at 8, 12, 16, 24, 32, and 48kHz. Usage of 40ms intervals includes all of the aforementioned sampling rates as well as 96kHz. 192kHz sampled conferences are only supported at 10 and 20ms mixing intervals. These limitations are imposed because higher mixing intervals at the higher sampling rates causes large increases in memory consumption. Adventurous users may, through changing of the MAX_DATALEN define in bridge_softmix.c allow 96kHz and 192kHz sampled conferences to operate at longer intervals - set to 16192 for 96kHz at 80ms or 32384 for 192kHz at 80ms, recompile, and restart.

Maximizing Performance

In order to maximize the performance of a given machine for ConfBridge purposes, there are several steps one should take.

  • Enable dsp_drop_silence is enabled in the User Profile.
    • This is the single most important step one can take when trying to increase the number of bridge participants that a single machine can handle. Enabling this means that the audio of users that aren't speaking isn't mixed in with the bridge.
  • Lengthen mixing_interval in the Bridge Profile.
    • The default interval is 20ms. Other options are 10, 40, and 80ms. Lower values provide a "tighter" sound, but require substantially more CPU. Higher values provider a "looser" sound, and consume substantially less CPU. Setting the value to 80 provides the highest number of possible participants.
  • Connect clients at the same sampling rate.
    • Requiring the bridge to resample between clients that use codecs with different sampling rates is an expensive operation. If all clients are dialed in to the bridge at the same sampling rate, and the bridge operates at that same rate, e.g. 16kHz, then the number of possible clients will be maximized.
  • Run Asterisk with a higher priority.
    • By default, Asterisk operates at a relatively normal priority, as compared to other processes on the system. To maximize the number of possible clients, Asterisk should be started using the -p (realtime) flag. If the load becomes too large, this can negatively impact the performance of other processes, including the console itself - making it difficult to remotely administer a fully loaded system.

As the number of clients approaches the maximum possible on the given machine, given its processing capabilities, audio quality will suffer. Following the above guidelines will increase the number of connected clients before audio quality suffers.

  • No labels


  1. ConfBridge is not a direct feature-to-feature replacement for MeetMe. We received a feature request for capability in ConfBridge that provides an equivalent for the start/endtime functionality that can be provided by MeetMe in the use of MeetMe in a realtime fashion (see the fuzzystart, earlyalert, and endalert options in meetme.conf). This capability can be produced in ConfBridge through dialplan magic:

    • For starting times, don't let someone execute the ConfBridge application until a certain time has been met or use func_curl to ask an external service if the caller should be allowed, and then carry on, or not.
    • For ending times, use the AMI or CLI (not preferred) functions to kick all users from a bridge when the desired end time is reached.
    • For the prompted alert, connect over AMI or CLI and originate a local channel into the conference that plays back some sort of "your call will end in X" seconds series of prompts.

    Alternately, we've considered that someone might want to write code into Confbridge to make this a simpler task. For that, we've come up with some ideas, that we'd love to see in the form of a patch contributed by a community member:

    User profile options for
    • start time (yyyy/mm/dd hh:mm:ss)
    • end time (yyyy/mm/dd hh:mm:ss),
    • announce not yet time (yes/no, if yes play announce not yet time sound prompt and continue in dialplan, if no just continue in dialplan)
    • announce net yet time sound file (file path)
    • announce end time (a time in seconds, the time after the beginning of the conference at which the announce end sound file is first played)
    • announce end time interval (interval in seconds; interval times after which announce end sound file is played)
    • announce end sound file (file path, the announcement played reminding of the end)
    • extension time allowed (yes/no)
    • extension time amount (time in seconds)
    • extension time announce first (a time in seconds, after the beginning of the conference, at which extension time announce sound is first announced) extension time announce sound (file)
    • extension time announce interval(interval in seconds after which extension time announce sound is repeated)
    • max extensions (integer, max # of extensions allowed to be added).
    Conference Menu item that can call the time extension.
    • conf_extend

    Accomplishing the above would allow someone to dynamically create conferences on the fly from the dialplan that mimicked the aforementioned simple functionality provided by MeetMe (without having to create external watcher scripts) and enhances it.

  2. Another missing feature is to specify the maximum length  of a conference – this is essential, if you record your disk could fill up if someone does not hang up!  I see this all the time in the conferences I am in charge of.

  3. It would be very helpful if you could add an increase and decrease volume for a user in the cli commands.  I now use meetme for that and have a dialplan with a series of prompt and use of the functions.

    1. We don't track feature requests sent to the wiki. If you have a patch then you can submit the feature on the bug tracker.

      Asterisk Issue Guidelines#Howtorequestafeature


    2. John you read my mind, that and being able to mute or onmute channels using a dialplan function instead. confbridge also is missing concise parameter to easily turn the data into a array instead of parsing the results using regex which is never perfect as some data might be empty