Conference bridge setup — multi-party PBX meetings

Conference bridges turn a PBX into a meeting platform — dial-in numbers, PIN-protected rooms, moderator controls, recording. Both FreePBX® (Asterisk® app_confbridge) and FusionPBX® (FreeSWITCH® mod_conference) have full support. This article covers the common patterns.

Sizing

• Each active conference participant uses 30-60 kbps of bandwidth (G.711 codec). 10-person conference: ~600 kbps.
• CPU: software audio mixing is moderate; a 4-vCPU VPS can host a couple of 30-person conferences simultaneously without struggling.
• RAM: conference state is small; per-call overhead is the dominant factor.

FreePBX setup

Admin → Applications → Conferences → Add Conference.

• Conference Number: the extension users dial to enter (e.g., 8000).
• Conference Name: human-readable label.
• User PIN / Admin PIN: optional pin entry. Admin can mute participants, kick, end meeting.
• Join Message: recording announcement, welcome, etc.
• Music on Hold: what plays when only one person is in the room.
• Quiet Mode: suppress join/leave announcements (useful for large bridges).
• Record Conference: writes a wav per conference session.

Apply Config; the conference is live at the extension you set.

FusionPBX setup

Applications → Conferences → Add. Configuration mirrors FreePBX:

• Domain (multi-tenant)
• Extension
• PIN numbers
• Max participants
• Recording options

FusionPBX adds:

• Conference Rooms as a hierarchical concept (multiple rooms per tenant).
• Active Conferences page showing real-time who's in each room.
• Web-based moderator controls — kick, mute, deaf participants from the UI without needing a moderator on the line.

Inbound DID routing to a conference

Customers usually dial a DID, not an internal extension. Route DID → conference:

FreePBX: Inbound Routes → set Destination = "Conferences: My Bridge". Caller hits the conference directly.

FusionPBX: Dialplan → Inbound Routes → set the destination expression to your conference extension.

PIN entry flow

With PINs enabled, caller hears: "Please enter the conference PIN." On valid PIN, they're announced (or not, per quiet mode) and dropped into the room. On invalid PIN: 3 tries, then hangup.

For semi-public conferences (recurring meeting with the same PIN), document the PIN somewhere that doesn't email or DM it (PIN-in-email gets indexed); for sensitive meetings, rotate PINs per meeting.

Audio quality considerations

• Force a consistent codec — set conference to G.711 explicitly. Mixed-codec conferences trigger transcoding for every participant, multiplying CPU use.
• Sample rate matters — confbridge default is 8 kHz; bumping to 16 kHz "wideband" audio (using G.722 or Opus) dramatically improves intelligibility for 5+ person calls. Costs more bandwidth + CPU.
• Echo cancellation — on by default in both engines; without it, the first conference will become an echo-fest.

Recording

Recordings drop into:

• Asterisk: /var/spool/asterisk/monitor/ by default.
• FreeSWITCH: /var/lib/freeswitch/recordings/.

Plan storage — a 60-minute G.711 mono recording is roughly 30 MB. Forty hours of recordings: ~1.2 GB. Off-host to S3-compatible storage if you keep long retention; see the related call-recording article in the call-center category.

WebRTC join (browser-based)

For meetings with users who don't have SIP phones:

• FreePBX: Webphone module (paid) or external softphone like sipml5 / JsSIP serving a WSS-connected page.
• FusionPBX: built-in mod_verto WebRTC support; bundled Verto Communicator works out of the box.

WebRTC requires proper TLS + WSS configuration; see the related WebRTC article.

When NOT to use the PBX conference

For video conferences, screen sharing, or 50+ participants, dedicated platforms (Jitsi self-hosted, Zoom/Meet for hosted) outperform a PBX bridge. The PBX bridge is good for audio-only, dial-in-friendly, recurring meetings where moderate participant counts (under ~30) are typical. Trying to scale a PBX bridge to 100+ participants stresses the engine in ways it wasn't designed for.