The Cisco Webex Realtime Bridge driver in MemberJunction's Realtime Bridges program. It connects
the one realtime agent engine to a Webex meeting: bidirectional audio, a diarized participant roster,
participant mute, Webex meeting chat, and a Meeting Controls facilitator channel — all behind an
injectable Cisco Webex Meetings SDK seam so the driver builds and unit-tests with no network and no real
Cisco Webex Meetings SDK. It is a structural mirror of the reference
@memberjunction/ai-bridge-zoom driver (and its sibling
@memberjunction/ai-bridge-teams).
See the Realtime Bridges Guide and
/plans/realtime/realtime-bridges-architecture.md
(§3 provider abstraction, §4b channels, §8 Cisco Webex capability row) for the full architecture.
npm install @memberjunction/ai-bridge-webex
WebexBridge — @RegisterClass(BaseRealtimeBridge, 'WebexBridge'). The MJ: AI Bridge Providers
row with DriverClass = 'WebexBridge' resolves to this driver via the ClassFactory. Implements the
four BaseRealtimeBridge abstracts (Connect / Disconnect / SendMedia / OnMedia) and the
capability-gated virtuals Webex supports (GetParticipants, OnParticipantChange), plus
GetMeetingControlsEventSource for the facilitator channel and a PostChatMessage helper.IWebexMeetingSdk — the injectable seam the driver depends on instead of the real SDK.WebexMeetingControlsEventSource — adapts the seam's roster / hand-raise / speaking / mute into
the bridge's IBridgeMeetingControlsEventSource, so the engine wires the Meeting Controls channel.| Capability | Status |
|---|---|
| On-demand + scheduled + invite join | ✅ |
| Inbound routing | ✅ |
| Audio in / out | ✅ |
| Video in/out, Screen in/out (directional flags) | ✅ (transport carries them; models light audio first) |
| Speaker diarization (roster + per-speaker labels) | ✅ |
| Participant mute (Meeting Controls) | ✅ |
| Webex meeting chat | ✅ |
| Native raised-hand | ⚠️ Partial — wired where the Meetings SDK surfaces it; tolerant of it never firing |
| DTMF / call transfer / recording | ➖ not Webex-meeting features here — the gated base methods throw BridgeCapabilityNotSupportedError |
Capability gating is two-layer (defense-in-depth): the engine checks the provider's SupportedFeatures
first, and the driver re-asserts each flag with RequireFeature at the top of its overrides.
Webex advertises everything Zoom does, plus InviteJoin and InboundRouting (the calendar-invite /
inbound-routing UX), and its native raised-hand is partial rather than fully reliable. Unlike Teams,
Webex does not advertise NativeInvite. Everything else (audio in/out, directional video/screen,
diarized roster, mute, meeting chat) maps one-to-one onto the Zoom reference driver.
IWebexMeetingSdk)The driver never imports the real Webex SDK. It depends only on this minimal interface, named after Cisco Webex Meetings SDK / xAPI / Webex bot concepts:
export interface IWebexMeetingSdk {
join(args: WebexJoinArgs): Promise<WebexJoinResult>;
leave(): Promise<void>;
sendAudioFrame(pcm: ArrayBuffer): void; // agent's voice out (outbound audio track)
onAudioFrame(cb: (frame: WebexAudioFrame) => void): void; // raw per-participant audio in (diarization)
onParticipantJoin(cb: (p: WebexParticipant) => void): void;
onParticipantLeave(cb: (id: string) => void): void;
onHandRaise(cb: (id: string, raised: boolean) => void): void; // ⚠️ partial on Webex
getParticipants(): Promise<WebexParticipant[]>;
postChatMessage(text: string): Promise<void>; // Webex meeting space chat
muteParticipant(participantId: string): Promise<void>;
onMeetingEnded(cb: () => void): void;
}
In production this is bound to the Cisco Webex Meetings SDK (the embedded-app / Web / mobile Meetings
SDK that joins the meeting and exposes media + the members roster) together with the Webex bot
framework (Webex Messaging API for the in-meeting space chat) and, where a Webex room device is involved,
the xAPI for participant actions. Supply a factory via the creation seam:
import { WebexBridge } from '@memberjunction/ai-bridge-webex';
// Once, where bridge drivers are configured:
// bridge.SetSdkFactory((config) => new RealWebexSdkAdapter(config));
// The adapter implements IWebexMeetingSdk over the real Webex SDK. The driver + its tests do not change.
Out of the box, WebexBridge ships without the real SDK adapter — Connect throws an explicit
"bind the real Cisco Webex SDK" error until SetSdkFactory is called. Tests inject a FakeWebexSdk.
The bridge is not used directly — AIBridgeEngine.StartBridgeSession (@memberjunction/ai-bridge-server)
resolves it from the provider's DriverClass, wires the transport seam to the injected
IRealtimeSession, and (when a channel host is supplied) wires the Meeting Controls channel from
GetMeetingControlsEventSource. See the bridge-server package and the guide's "Channel plane" section.
FakeWebexSdk (in src/__tests__/) is an in-memory IWebexMeetingSdk with drive helpers and capture
sinks. The suite covers connect/disconnect (incl. parsing the meeting number out of the join link),
audio in→OnMedia (speaker labels) and out→seam, participant join/leave → roster + event source, native
hand-raise → Meeting Controls perception, capability gating (a feature Webex lacks throws), and chat — all
with no network.
cd packages/AI/Providers/BridgeWebex && npm run test