---
title: "WhatsMCP SIP Trunk — WhatsApp Voice on Your PBX"
description: "A two-way SIP bridge that terminates WhatsApp voice on any standard PBX. Opus and MLow transcoded at the edge, E.164 routing, SIP over TLS."
url: "https://whatsmcp.com/sip"
---

SIP trunk · beta

# 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.

[Request Trunk](https://whatsmcp.com/contact?inquiry=sip-trunk) [Request documentation](https://whatsmcp.com/contact?inquiry=sip-trunk)

## Topology & media path

A two-way bridge: calls originate on either side and terminate on the other.

WhatsApp client

Opus · MLow

inbound · WhatsApp → PBX

outbound · PBX → WhatsApp

Signalling + media

WhatsMCP edge

`transcode` `E.164`

INVITE → trunk

INVITE ← trunk

Your PBX

G.711 · G.722 · Opus

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.

Codecs

## 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 frames`
    
    WhatsApp’s normal wideband codec, and what a healthy call negotiates.
    
-   MLow `Meta’s low-bitrate codec`
    
    What WhatsApp falls back to when the far end is on a constrained network. Proprietary — there is no PBX on the market that decodes it.
    

transcode

### Trunk side

-   G.711 `µ-law / A-law · 8 kHz`
    
    The universal fallback. Every core in the tested list speaks it.
    
-   G.722 `wideband · 16 kHz`
    
    Keeps the call wideband end to end where your handsets support it.
    
-   Opus `48 kHz`
    
    Negotiated 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.

Capabilities

## 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.

Device role

## 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 |

Beta

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.

Egress nodes

## 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.

WireGuard

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.

SOCKS5

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.

egress

```
# 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:+447700900000@sip.whatsmcp.com:5061
```

#### Tested PBX cores

`Asterisk 18+` `FreeSWITCH` `Kamailio` `FreePBX`

FAQ

## 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.

## Put a number on the wire.

[Request Trunk](https://whatsmcp.com/contact?inquiry=sip-trunk)

Trunks are provisioned by hand during the beta.