SIP Signaling From the Wire Up: Part 10 of 12
Everything we've covered so far has been about SIP communication between endpoints on a network, phones talking to PBX systems, phones talking to each other through proxies. But most businesses also need to make and receive calls to and from the public telephone network: landlines, mobile phones, and anyone who isn't on your SIP system. That connection between your SIP infrastructure and the public phone network is a SIP trunk.
SIP trunking replaced the older model of connecting to the phone network through physical circuits like PRI (Primary Rate Interface) lines, which used dedicated T1 or E1 circuits with ISDN signaling. A PRI gave you a fixed number of channels (typically 23 voice channels on a T1) over a dedicated physical connection. SIP trunking provides the same connectivity, calls to and from the public phone network, but over your existing internet connection using SIP signaling. This is the shift that made physical phone lines obsolete: capacity became a contract term rather than a count of copper pairs.
How a SIP trunk works
A SIP trunk is a logical connection between your PBX and an Internet Telephony Service Provider (ITSP), which is the company that bridges SIP traffic to the public switched telephone network (PSTN). The ITSP operates gateway equipment that converts between SIP/RTP on the internet side and the traditional telephone network signaling (SS7, ISDN) on the PSTN side.
When someone in your office dials an outside number, the call flows like this:
- The desk phone sends a SIP INVITE to your PBX
- Your PBX determines this is an outbound call (not an internal extension) and routes it to the SIP trunk
- The PBX sends a SIP INVITE to the ITSP's SBC with the dialed number
- The ITSP's equipment converts the SIP signaling to PSTN signaling and connects the call into the telephone network
- The call reaches the destination phone through the traditional phone network
Inbound calls follow the reverse path. Someone dials your business phone number. The call arrives at the ITSP through the PSTN. The ITSP converts it to a SIP INVITE and sends it to your PBX. Your PBX routes it to the appropriate extension.
Trunk authentication models
SIP trunks use one of two authentication approaches, and understanding which one your trunk uses matters for both configuration and troubleshooting.
IP based authentication
With IP authentication, the ITSP configures their SBC to accept traffic from your PBX's public IP address. No SIP registration is needed. Your PBX simply sends INVITEs to the ITSP's SBC address, and the ITSP accepts them because the source IP matches their configuration.
An outbound call over an IP authenticated trunk looks like this:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5060;branch=z9hG4bK4432
Max-Forwards: 70
To: <sip:[email protected]>
From: "Main Office" <sip:[email protected]>;tag=as2e0398f
Call-ID: [email protected]
CSeq: 102 INVITE
Contact: <sip:203.0.113.1:5060>
Content-Type: application/sdp
Content-Length: 245
[SDP body]
Notice the Request-URI contains the dialed number in E.164 format (the international numbering standard, with a + prefix and country code). The From header contains the caller's phone number, which the ITSP will use for outbound caller ID. The Contact header shows the PBX's public IP address.
The ITSP's SBC sees the INVITE arriving from 203.0.113.1, checks that this IP is authorized, and processes the call. No 401 challenge is needed.
IP authentication is simple and common for on premises PBX deployments with static public IP addresses. The main requirement is that your PBX has a consistent public IP, which means either a static IP from your ISP or a consistent NAT mapping. If your public IP changes (common with residential grade internet connections), the ITSP's configuration will be wrong and your calls will fail until the IP is updated.
Registration based authentication
With registration authentication, your PBX registers with the ITSP just like a phone registers with a PBX. The PBX sends a REGISTER to the ITSP's SBC, goes through the digest authentication challenge, and maintains an active registration. Calls are then sent within the context of that registration.
REGISTER sip:provider.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK771
Max-Forwards: 70
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=reg38
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:10.0.0.1:5060>
Expires: 3600
Content-Length: 0
Registration authentication is more flexible because it works regardless of the PBX's public IP. The ITSP identifies the trunk by the registration credentials, not the source IP. This makes it suitable for PBX systems behind dynamic IPs, and it's the more common model for cloud hosted PBX platforms.
The tradeoff is that the registration needs to be maintained. If registration fails or expires, the trunk goes down. All the registration troubleshooting concepts from post 4 apply here: credential errors, firewall issues, NAT timeouts, and DNS failures can all prevent the trunk from registering or staying registered.
Codec negotiation on trunks
When a call crosses a SIP trunk, codec negotiation happens between your PBX and the ITSP's SBC, independently of whatever codec is being used on the internal leg between the phone and the PBX.
Most ITSPs support G.711 (both PCMU and PCMA) as a baseline because G.711 is the standard encoding of the PSTN. When a call enters or exits the traditional phone network, it's G.711. If your trunk is also using G.711, there's no transcoding needed at the ITSP's gateway, which is ideal for quality.
Many ITSPs also support G.729, which uses significantly less bandwidth than G.711 (about 8 kbps versus 64 kbps per call). If bandwidth is limited, G.729 on the trunk can be a reasonable tradeoff. But G.729 is a lossy compression codec, and if your internal phones are also using G.729, the audio has been compressed and decompressed twice by the time it reaches the far end (once on the internal leg, once on the trunk), which compounds quality degradation.
Some modern ITSPs support Opus on their trunks, which can provide better quality than G.711 at comparable or lower bitrates. Support for Opus on SIP trunks is growing but not yet universal.
The codec negotiation appears in the SDP, as covered in post 5. If you're troubleshooting a 488 Not Acceptable Here on an outbound call, the codec lists in your PBX's INVITE and the ITSP's supported codecs don't overlap.
Trunk capacity
A PRI gave you a fixed number of channels, typically 23 on a T1. You could make or receive exactly 23 simultaneous calls, no more. SIP trunks are more flexible, but capacity is still a consideration.
Some ITSPs sell trunk capacity as a fixed number of concurrent channels, similar to a PRI. You buy 10 channels, you can make 10 simultaneous calls. Others sell unlimited concurrent calls and rely on your internet bandwidth being the practical limit. Still others dynamically adjust capacity based on your subscription level. Keep in mind that a channel you bought is not always a channel the provider can deliver at peak: most ITSPs overbook their capacity to some degree, and how aggressively they do it is a big part of why per-channel pricing varies so much.
From a SIP perspective, there's no inherent limit. Each call is an independent INVITE transaction. The limits come from three places: the ITSP's policy (how many concurrent calls they allow for your account), your PBX's capacity (how many calls it can process simultaneously), and your internet bandwidth (how many RTP streams your connection can carry).
If you exceed your trunk's channel limit, additional outbound INVITEs will typically be rejected with a 503 Service Unavailable or a 486 Busy. Inbound calls that exceed capacity may get a busy signal or go to a voicemail server if one is configured. A bandwidth calculator can help you estimate how many concurrent calls your connection can support based on codec and overhead.
Phone number management
SIP trunks carry your business phone numbers. These numbers, called DIDs (Direct Inward Dialing numbers), are assigned to your account by the ITSP and mapped to your SIP trunk. When someone dials one of your DIDs, the call arrives at the ITSP, which sends a SIP INVITE to your PBX with the dialed DID in the Request-URI.
Your PBX then uses the dialed DID to determine where to route the call internally. A call to your main number might go to an auto attendant. A call to a direct line might go straight to a specific extension. The DID in the incoming INVITE is what makes this routing possible.
When an INVITE arrives from the ITSP for an inbound call, it typically looks something like this:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TLS sbc.provider.com:5061;branch=z9hG4bK88a3
...
To: <sip:[email protected]>
From: "John Doe" <sip:[email protected]>;tag=prov334
...
The Request-URI and To header contain the DID that was dialed (+15559876543). The From header contains the calling party's number (+15551234567). Your PBX reads the DID from the Request-URI, matches it against its inbound routing rules, and sends the call to the right destination.
Number porting
When a business switches to a new ITSP or moves to a SIP trunk from a traditional phone line, they usually want to keep their existing phone numbers. Number porting is the process of transferring number ownership from one carrier to another.
At the SIP level, porting doesn't change anything. Once the numbers are ported to the new ITSP, inbound calls arrive as SIP INVITEs just like before. The porting process itself is a carrier level administrative process that typically takes one to four weeks, during which nothing changes on the technical side. On the cutover date, the numbers switch to the new carrier, and calls start arriving on the new trunk.
The risks during porting are mostly operational. If the porting process is delayed or has errors, calls to the ported numbers may fail during the transition. Having both the old and new service active during the porting window provides a safety net.
SIP trunking versus hosted PBX
It's worth clarifying the distinction between SIP trunking and a hosted PBX, because the terms are sometimes used interchangeably even though they describe different architectures.
With SIP trunking, you operate a PBX (either a physical server in your office or a virtual machine) that handles all call routing, voicemail, auto attendant, and extension management. The SIP trunk provides only the connection to the outside world. You manage the PBX. The ITSP manages the trunk.
With a hosted PBX (also called cloud PBX or UCaaS), the PBX itself is run by the provider. Your phones register directly to the provider's servers, and the provider handles everything: internal call routing, voicemail, trunking to the PSTN, and all the features. You don't have a PBX to manage.
The SIP signaling is similar in both cases. Phones still send INVITEs, still register, still negotiate codecs through SDP. The difference is who manages the infrastructure and where the intelligence lives. From a troubleshooting perspective, the main impact is that with SIP trunking you have access to the PBX logs and can see both sides of the trunk. With a hosted PBX, you can see the phone side but the server side is in the provider's cloud, and you depend on their support team for visibility into that part of the path.
Next up: Reading a SIP Trace: Practical Troubleshooting. Time to get hands on with the tools you'll use to capture and analyze SIP traffic.
Share
Want to know when we publish new articles? Sign up for updates