On a Yeastar P-Series PBX, a carrier SIP trunk is added under Extension and Trunk › Trunk › Add — select the “General” ITSP template, pick the right trunk type (Register for username/password carriers, Peer for IP authentication), and enter the carrier’s hostname. Unlike some commercial PBXes, Yeastar doesn’t gate custom carriers behind a license tier: any SIP carrier works on any P-Series edition — appliance, software, or cloud.
The platform’s trunk model has one decision and two quirks that cause most failed setups. This guide — written by SIPNEX, an FCC-licensed carrier — covers all three.
The one decision: trunk type
Yeastar offers three SIP trunk types, and they describe who registers to whom:
- Register Trunk — your PBX registers out to the carrier with a username and password. The right choice for most carrier accounts, and the simplest behind dynamic IPs.
- Peer Trunk — no registration; the carrier authenticates your PBX’s IP address. Choose this for IP-auth accounts on a static public IP.
- Account Trunk — the direction reverses: the PBX acts as the registrar and something registers in to it. You will rarely want this for a carrier connection.
Picking the wrong direction is the classic dead-trunk mistake. If your carrier issued credentials, it’s a Register Trunk; if it asked for your static IP, it’s a Peer Trunk. SIPNEX supports both — credentials or IP whitelisting, provisioned within a business day.
Adding the trunk
- Extension and Trunk › Trunk › Add. Name the trunk, set Trunk Status to Enabled, and choose Select ITSP Template › General.
- Set the Trunk Type (Register or Peer, per above).
- Hostname/IP and Port: your carrier’s SIP server, typically port 5060.
- The Domain quirk: Yeastar’s Domain field feeds the SIP From/To URIs. If your carrier doesn’t specify a separate domain — most don’t — enter the same value as Hostname/IP. Leaving Domain empty is one of the most common misconfigurations on this platform.
- Register trunks: enter Username, Password, and Authentication Name (usually identical to the username).
- Transport: UDP unless your carrier provisioned TCP or TLS.
DIDs and inbound routing — the second quirk
Add your numbers on the trunk’s DIDs/DDIs tab, then build an inbound route: Call Control › Inbound Routes › Add, select the trunk, set the DID Pattern, and pick the destination (extension, queue, IVR, ring group).
Here is the quirk: the DID Pattern matches against whatever the PBX extracts from the carrier’s INVITE, controlled by “Get DID From” on the trunk’s SIP Headers tab (To, Invite/Request-URI, Diversion, P-Asserted-Identity, and so on). If a carrier puts the DID in the To header while the trunk reads the Request-URI, your inbound route silently never matches. When inbound calls all fall through to the default destination, this setting is the first thing to check.
Outbound caller ID lives on the trunk’s Outbound Caller ID tab — trunk-level default plus per-extension overrides where the carrier permits them.
Codecs, DTMF, and NAT
On the trunk’s Advanced tab:
- Codec Setting: order your codecs — for US carrier trunks, u-law (G.711u) first, with G.729 as the bandwidth fallback.
- DTMF Mode: RFC4733 (the current name for RFC 2833) is what carriers expect; Auto negotiates it when the far end supports it.
- Enable RTP Keep-alive and Qualify (SIP OPTIONS heartbeats) keep NAT pinholes open and let the PBX detect a dead carrier link.
NAT is configured system-wide under System › Network › Public IP and Ports: set External IP Address for a static public IP, External Host for dynamic-IP sites, or STUN — and fill in Local Network Identification so LAN traffic isn’t rewritten. Forward SIP UDP 5060 and the RTP range (default UDP 10000–12000, adjustable under PBX Settings › SIP Settings) on the firewall, and disable SIP ALG on the router.
Testing
Register trunks show their registration state on the trunk list — confirm it before anything else. Then test outbound to a mobile (verify caller ID) and inbound to each DID (verify the route destination). Inbound falling to the default destination means the DID Pattern and “Get DID From” disagree — see the quirk above.
Frequently asked questions
What’s the difference between a register trunk and a peer trunk on Yeastar?
A register trunk authenticates outward with a username and password — your PBX registers to the carrier. A peer trunk skips registration entirely; the carrier trusts your static IP instead. Use register for credential-based accounts and dynamic IPs, peer for IP-authentication accounts on a fixed public IP.
What goes in Yeastar’s Domain field for a SIP trunk?
Whatever your carrier specifies — and if it specifies nothing, repeat the Hostname/IP value. The field populates the SIP From/To URIs, and Yeastar’s own documentation instructs duplicating the hostname when the ITSP provides no separate domain. Leaving it blank is a frequent cause of rejected calls.
Why do my inbound calls ignore the Yeastar inbound route?
Usually because the DID Pattern doesn’t match what the trunk extracts from the INVITE. Check “Get DID From” on the trunk’s SIP Headers tab — if the carrier delivers the DID in the To header but the trunk reads the Request-URI (or vice versa), the route never matches and calls fall to the default destination.
Does Yeastar restrict which SIP carriers I can use?
No. The ITSP template list is a convenience, not a gate — the General template accepts any SIP carrier on every P-Series edition. Capacity (extensions, concurrent calls) depends on your model and plan, but trunk creation itself is a base feature.
SIPNEX provisions SIP trunks for any PBX — register or peer, unlimited channels, A-level STIR/SHAKEN attestation under our own certificate, with engineers who know which header your DID is hiding in. Connect your PBX or see rates.
Keep reading.
The carrier built by operators, for operators.
FCC-licensed carrier with its own STIR/SHAKEN SP certificate. Operator-owned. SIP trunks built for operators who dial at volume.