How to connect a PBX to a SIP trunk

Before you start

Connecting an IP PBX to a SIP trunk follows the same pattern on almost every platform, whether it is Asterisk, FreePBX, 3CX, FreeSWITCH or a hardware appliance. The screens and field names differ; the decisions do not. This guide walks through those decisions in the order you will meet them, then covers testing and the faults that appear most often.

You will need:

• Administrative access to the PBX and to the firewall or router in front of it.
• The configuration sheet from your SIP provider (described in the next section).
• A list of the numbers on the trunk and where each one should ring.
• A maintenance window, if the PBX is already carrying live calls on other lines.

Back up the PBX configuration before you change anything, and keep existing lines in service until the new trunk has passed every test.

Gather the trunk details

Your provider should give you a configuration sheet. If any item below is missing, ask for it before you start, as guessing values is the most common cause of a long first day.

If your PBX has a static public IP address, IP authentication is usually the simpler and more secure choice. If the address can change, use registration with a long, random password.

Prepare the firewall and NAT

Most installation problems are network problems. SIP carries IP addresses inside its messages, so a router that translates addresses without understanding SIP can break calls in ways that look like PBX faults. Work through these items before creating the trunk.

1. Disable SIP ALG. Many routers include a SIP Application Layer Gateway that rewrites SIP messages. Implementations are often unreliable and cause failed registrations, dropped calls and one-way audio. Turn it off unless your provider specifically asks you to keep it.
2. Allow signalling from the provider only. Permit SIP traffic on the agreed port from the provider’s signalling addresses, and block SIP from everywhere else. An open SIP port attracts constant scanning.
3. Open the RTP port range. Audio travels on a range of UDP ports separate from signalling. Check the range configured on your PBX (on many Asterisk-based systems the default is 10000 to 20000) and allow it from the provider’s media addresses.
4. Set the public address on the PBX. If the PBX sits behind NAT, enter its public IP address (often called the external address) and list your local networks. Without this, the PBX advertises a private address and the provider cannot send audio back.
5. Check UDP timeouts. If you use registration over UDP, make sure the firewall keeps the session open for longer than the registration interval, or enable keep-alive messages on the PBX.

Create the trunk

With the network ready, create the trunk on the PBX using the values from the configuration sheet. Keep the first configuration minimal: one transport, one or two codecs, one DTMF method. Extra options can be added once basic calls work.

; Example only. Field names follow a FreePBX-style PJSIP trunk and
; vary by platform and version. Replace every placeholder with the
; values on your provider's configuration sheet.

Trunk name ............ provider-main
Outbound caller ID .... +442079460000
Maximum channels ...... 10
SIP server ............ SIP-HOST-FROM-CONFIG-SHEET
SIP server port ....... 5060
Transport ............. UDP
Authentication ........ None (IP authentication) or Outbound (registration)
Registration .......... None (IP authentication) or Send (registration)
Username / secret ..... only if using registration
Codecs (in order) ..... G.711 A-law, G.711 u-law
DTMF mode ............. RFC 4733
Inbound context ....... from-pstn
Match / permit ........ PROVIDER-SIGNALLING-IP

Points that are easy to miss:

• Restrict the codec list to those on the configuration sheet, in the same order. Offering codecs the trunk does not support can cause failed calls.
• Set a channel limit on the PBX that matches the trunk, so calls beyond the limit fail predictably rather than at the provider.
• Disable direct media (sometimes called re-invite or media bypass) at first, so audio flows through the PBX, which has the correct NAT settings.
• For registration trunks, confirm the PBX shows the trunk as registered before testing calls.

Set up inbound routes

An inbound route matches the number that was dialled and sends the call to a destination: an extension, ring group, queue, IVR menu or time condition. Each number on the trunk needs a route, either its own or a shared catch-all.

Match the number exactly as the provider delivers it. If the configuration sheet says inbound numbers arrive as +442079460123, a route written for 02079460123 will not match and the call will be rejected or sent to a default destination. When in doubt, place a test call and read the dialled number from the PBX log or call record.

Add a catch-all route that sends unmatched numbers to an operator or announcement, rather than letting calls fail silently. It will catch numbers that were ported in later and forgotten.

Outbound routes and dial plan

Users dial numbers the way they always have: a local number, a national number with a leading zero, or an international number with an exit code. The trunk usually expects one consistent format, most often E.164, the international format with a country code and no leading zero. The outbound route translates between the two.

; Example only. Generic outbound normalisation rules assuming UK
; dialling conventions and a trunk that expects E.164 with a leading +.
; Translate the patterns into your PBX's dial plan syntax.

User dials               Sent to the trunk as
-----------------------  ------------------------------------------
0 + national number      +44 followed by the number (drop the 0)
00 + country + number    + followed by country + number
+ country + number       unchanged
Emergency numbers        as specified by your provider; never blocked

Build routes for the destinations you actually need, not a single pattern that matches everything. Separate routes for national, mobile and international calls let you restrict international and premium-rate dialling to the users who need it, which is one of the most effective controls against toll fraud.

Configure caller ID

Set a default outbound caller ID on the trunk, usually your main number, and override it per extension where users have direct numbers. Send it in the format the provider expects, normally E.164.

You may only present numbers that are assigned to you or that you are authorised to use. Many providers reject or replace caller ID that does not match a number on the account, and rules on presentation vary by country. If calls fail with a 403 response only when a particular caller ID is set, this is the likely reason.

Test before go-live

Work through a written test plan and record the result of each test. A practical minimum:

1. Inbound, per number. Call every number on the trunk from an outside line and confirm it reaches the intended destination, with audio in both directions.
2. Outbound, per destination type. Call a landline, a mobile and, if enabled, an international number. Confirm the caller ID the called party sees.
3. DTMF. Navigate an external IVR menu outbound, and your own menu or voicemail inbound.
4. Long calls. Hold at least one call for more than 15 minutes. Calls that drop at a consistent time usually point to session timer or NAT timeout problems that short test calls will not reveal.
5. Concurrent calls. Place several calls at once to confirm the channel limit behaves as expected.
6. Failover. If inbound failover is configured, make the PBX unreachable and confirm calls reach the alternate destination.
7. Transfers and hold. Transfer an inbound call to another extension and to an external number, and check music on hold.

Common SIP errors

When a call fails, the SIP response code in the PBX log is the quickest route to the cause. These are the codes you are most likely to see while bringing a trunk into service.

A call that connects and then drops after about 32 seconds is a distinct case: the provider did not receive the PBX’s acknowledgement of the answered call. This is almost always a NAT or contact address problem rather than a trunk fault.

One-way or missing audio

If calls connect but one or both parties hear nothing, signalling is working and media is not. The causes are almost always on the network side:

• SIP ALG still active on a router or firewall, rewriting the media address in the call setup.
• Missing external address on the PBX, so it advertises a private IP for audio.
• RTP ports blocked or not forwarded, or a range on the firewall that does not match the PBX.
• Direct media enabled, so the provider is told to send audio straight to a phone behind NAT.
• Asymmetric routing on sites with two internet connections, where audio leaves by one link and returns by the other.

A packet capture on the PBX, taken during a test call, shows which addresses each side is advertising and whether RTP is arriving. Share it with your provider if the cause is not clear; it shortens diagnosis considerably.