Real WhatsApp voice, terminated over SIP.
A pure signalling and media bridge for voice engineers. Calls cross in both directions, WhatsApp's Opus and MLow are transcoded at the edge to whatever your trunk speaks, and a plain E.164 number reaches any standard PBX.
Topology & media path
A two-way bridge: calls originate on either side and terminate on the other.
transcode E.164 Both directions, one trunk. A WhatsApp call rings your dialplan as an ordinary SIP INVITE; an extension dialling an E.164 number reaches that person on WhatsApp. The edge holds the leg on each side and translates between them — it is not a gateway you place calls through in one direction only.
Opus and MLow in, whatever your trunk speaks out.
WhatsApp picks its own codec per call and can change it mid-call as the network moves. Your dialplan never sees that: the edge terminates the WhatsApp leg, decodes it, and re-encodes into the codec your trunk negotiated.
WhatsApp side
- Opus
48 kHz, 20 ms framesWhatsApp’s normal wideband codec, and what a healthy call negotiates.
- MLow
Meta’s low-bitrate codecWhat WhatsApp falls back to when the far end is on a constrained network. Proprietary — there is no PBX on the market that decodes it.
Trunk side
- G.711
µ-law / A-law · 8 kHzThe universal fallback. Every core in the tested list speaks it.
- G.722
wideband · 16 kHzKeeps the call wideband end to end where your handsets support it.
- Opus
48 kHzNegotiated straight through when your trunk offers it — the fewest conversions.
Transcoding is not free. Every conversion costs a few milliseconds and, going through narrowband, some audio quality — G.711 is 8 kHz whatever went in. Offer Opus on your trunk if you can: it is the one path where the media crosses the bridge without being re-encoded.
What you get on the wire.
Two-way by default
Inbound WhatsApp calls ring your dialplan; extensions dial WhatsApp numbers back out. One trunk, both directions.
Transcoded at the edge
Opus and MLow are decoded and re-encoded into G.711, G.722 or Opus. Your PBX never learns that MLow exists.
E.164 in your dialplan
WhatsApp IDs are normalised to strict E.164 before they reach you, so existing routing rules match without modification.
SIP over TLS
Signalling runs over TLS to your border. Media is SRTP where your core negotiates it.
Bring your own egress
Pin an account’s WhatsApp traffic to a WireGuard peer or a SOCKS5 proxy you control, per number.
Standard cores only
Asterisk, FreeSWITCH, Kamailio and FreePBX are what we test against. No agent, no module, no fork of your PBX.
Either device role
Attach the trunk to a dedicated number or to one already on somebody’s handset — the trunk sees the same E.164 either way.
Readable call records
Direction, peer, answered, duration and the negotiated codec for every leg, exported through the same account tooling.
Primary or secondary — the trunk is identical.
Every WhatsApp number the bridge terminates is attached in one of two roles. The choice changes how the account is registered and who else holds the number; it does not change your dialplan, your codecs, or the SIP URI you route to.
| Property | Primary device | Secondary (companion) |
|---|---|---|
| Registration | SMS or voice code, standalone | QR scan from an existing handset |
| Handset required | No — the number lives on the trunk | Yes — it stays the primary device |
| Transport to WhatsApp | Direct TCP (443 / 5222) | WebSocket, like WhatsApp Web |
| Number is shared with | Nothing else | The phone, and its other linked devices |
| Best for | A dedicated trunk number | Putting a number people already use on the trunk |
| What the trunk sees | One E.164 number | The same one E.164 number |
Secondary is the mode the MCP product pairs in today: the handset stays primary and keeps receiving the calls it always did. Tell us which role you need when you request a trunk.
Choose where the WhatsApp leg leaves.
The SIP side of the bridge terminates on your trunk, at an address you already control. The WhatsApp side leaves through our egress by default — nominate your own node instead and that account’s traffic exits where you say it does.
peer config
Hand us a peer and the account’s WhatsApp traffic rides your tunnel. The exit is an address you own and can attest to.
user + password
A plain authenticated proxy where a tunnel is more than you want to run. Same effect on the exit IP, less to operate.
- Set per account — one number can use your egress while another leaves through ours.
- Your network policy and your data-residency rules applied to the session itself.
- A stable exit address: it does not rotate when ours does.
What it isn’t: a way to avoid being blocked. Egress control decides where your traffic goes. It does not change what WhatsApp does with the account, and the terms below still apply.
# SOCKS5 socks5://user:••••••@203.0.113.10:1080 # …or a WireGuard peer [Peer] PublicKey = 8Nd…= Endpoint = 203.0.113.10:51820 AllowedIPs = 0.0.0.0/0
E.164 call routing logic
Inbound WhatsApp calls do not carry traditional caller ID. The bridge normalises WhatsApp IDs into strict E.164 before they hit your dialplan, so existing routing rules work without modification.
Normalisation: In: wa_id=447700900000 Out: +447700900000 SIP URI generated: sip:[email protected]:5061
Tested PBX cores
Asterisk 18+ FreeSWITCH Kamailio FreePBX Common questions about the trunk.
Which PBX platforms does the SIP trunk work with?
Asterisk 18+, FreeSWITCH, Kamailio and FreePBX are what we test against — no agent, no module, no fork of your PBX.
Does WhatsApp's MLow codec work with a standard PBX?
No PBX on the market decodes MLow, the proprietary codec WhatsApp falls back to on constrained networks. The bridge transcodes it — and Opus — at the edge into whatever your trunk speaks: G.711, G.722 or Opus straight through.
Can I put a number that already has a phone on it onto the trunk, or does it need to be dedicated?
Either. Attach a dedicated number as a standalone registration, or pair an existing handset's number as a secondary device over a QR scan — the phone stays primary. The trunk sees the same E.164 number either way; secondary/companion is the mode available today.
Can I control where WhatsApp-side traffic exits to the internet?
Yes, per account. Nominate a WireGuard peer or a SOCKS5 proxy and that number's WhatsApp traffic exits through your node instead of the default egress. It changes where the traffic goes, not what WhatsApp does with the account — WhatsApp's terms still apply.
How do inbound WhatsApp calls reach my dialplan without normal caller ID?
WhatsApp IDs are normalised into strict E.164 before they hit your dialplan, so existing routing rules match without modification.
Unofficial, and honest about it.
WhatsMCP speaks the WhatsApp protocol directly. It is not affiliated with Meta, and running it is outside WhatsApp's terms of service. Numbers can be blocked. Think hard before you put a number you care about on it — and don't spam.