@memberjunction/ai-bridge-vonage

The Vonage Realtime Bridge driver — a telephony bridge in MemberJunction’s Realtime Bridges program, mirroring the reference telephony driver @memberjunction/ai-bridge-twilio. It connects the one realtime agent engine to a phone call over the Vonage Voice API + websocket media: outbound dial, inbound DID routing, single-party audio in/out, DTMF send/receive, and call transfer — all behind an injectable telephony call SDK seam so the driver builds and unit-tests with no network and no real Vonage client.

A phone call goes through the same transport seam as every meeting bridge — it is just a single-leg audio media source. Telephony is audio only: no video, no screen, and no Meeting Controls / facilitator surface (a 1:1 call has no roster to facilitate).

See the Realtime Bridges Guide (§ Telephony bridges) and /plans/realtime/realtime-bridges-architecture.md (§8 Vonage capability row, §9 Phase 6) for the full architecture.

Install

npm install @memberjunction/ai-bridge-vonage

What it provides

• VonageBridge — @RegisterClass(BaseRealtimeBridge, 'VonageBridge'). The MJ: AI Bridge Providers row with DriverClass = 'VonageBridge' resolves to this driver via the ClassFactory. It is a thin subclass of BaseTelephonyBridge — all call lifecycle, the audio media seam, DTMF, transfer, the caller+agent roster, and capability gating are inherited. The driver only binds the Vonage SDK factory.
• VonageCallSdk — the Vonage binding of the platform-agnostic ITelephonyCallSdk seam over the Vonage Voice API + websocket media. Ships unbound (every op throws “bind the real Vonage client”) until a deployment supplies IVonageClientBindings over the real @vonage/server-sdk.
• VonageCallSdkFactory — the creation seam that builds a VonageCallSdk from resolved config.

Capability coverage (the Vonage seed row)

Capability	Status
Outbound dial	✅
Inbound DID routing	✅
Invite (DID identity)	✅
Audio in / out	✅
DTMF send / receive	✅
Call transfer	✅
Video / screen	➖ n/a — telephony is audio only (SendMedia no-ops video/screen out)
Meeting Controls / facilitator	➖ n/a — a 1:1 call has no roster (GetMeetingControlsEventSource → null)
Recording	➖ not enabled on the seed row — StartRecording stays capability-gated and throws

Capability gating is two-layer (defense-in-depth): the engine checks the provider’s SupportedFeatures first, and the base re-asserts each flag with RequireFeature at the top of its overrides.

Outbound vs inbound

The shipped RealtimeBridgeContext is a meeting-shaped contract with no Direction field, so the engine forwards the session’s direction (and the agent’s caller-id / the inbound call id) into the driver’s Configuration:

Config key	Purpose
Direction	'Outbound' (default) → sdk.dial(to, from); 'Inbound' → sdk.answer(callId)
FromNumber	the agent’s Vonage number / DID outbound calls originate from
InboundCallId	the platform call UUID of the inbound call to answer (from the inbound webhook)

Connect requires AudioIn + AudioOut; outbound additionally requires OutboundDial, inbound requires InboundRouting.

The Vonage binding (deployment TODO)

VonageCallSdk maps the telephony seam onto Vonage’s two halves — the Voice API (place/modify/hang-up, driven by NCCO documents) and the websocket media leg the call connects to (bidirectional realtime audio + DTMF):

ITelephonyCallSdk op	Vonage binding
dial (outbound)	Voice API POST /v1/calls with an NCCO whose connect action opens a bidirectional websocket → call UUID
answer (inbound)	the inbound answer webhook returns an NCCO with a connect websocket action; accept the websocket for the call UUID
hangup	Voice API PUT /v1/calls/:uuid with { action: 'hangup' }
sendAudioFrame	outbound websocket media frame (the agent’s voice)
onAudioFrame	inbound websocket media frames (single remote party)
sendDtmf	Voice API PUT /v1/calls/:uuid/dtmf with { digits } (or an NCCO input action)
onDtmf	NCCO input (dtmf) results delivered to the event webhook
transfer	Voice API PUT /v1/calls/:uuid with { action: 'transfer', destination: { type: 'ncco', ncco: [...] } }
onCallEnded	the event webhook (completed/failed/rejected/cancelled) or the websocket close event

Out of the box VonageCallSdk is unbound — every operation throws an explicit “bind the real Vonage client” error. Bind the real client by supplying an IVonageClientBindings (Voice API + websocket) when constructing the SDK; the driver and its tests do not change, and none of the @vonage/server-sdk types leak into this package. Credentials (API key, API secret, the Voice application id + private key, the websocket media URL) resolve through MJ’s credential system referenced by the provider Configuration — never inline secrets.

Usage (engine-driven)

The bridge is not used directly — AIBridgeEngine.StartBridgeSession (@memberjunction/ai-bridge-server) resolves it from the provider’s DriverClass, forwards the session Direction / caller-id into the driver config, and wires the transport seam to the injected IRealtimeSession. There is no channel host to wire for telephony (no Meeting Controls).

Testing

FakeVonageCallSdk (in src/__tests__/) is an in-memory ITelephonyCallSdk with drive helpers and capture sinks. The suite covers outbound dial → connect → audio round-trip (in/out), inbound answer, DTMF send + receive, transfer (gated), hangup + onCallEnded, the single caller+agent roster, capability gating (video/screen/Meeting Controls correctly absent), and the unbound-VonageCallSdk bind-me throw — all with no network.

cd packages/AI/RealtimeBridge/Providers/Vonage && npm run test