What is a carrier for my SIP or PSTN service?

When calls fail or show wrong caller ID, everyone blames “the line”, but very few people know what the carrier is actually doing.

A carrier is the telecom provider that connects my PBX to the outside world, delivering phone numbers, routing calls over SIP or PSTN, and enforcing numbering, caller ID, and regulatory rules.

Inside my network, the PBX decides how to route extensions, intercoms, and paging. At the edge, the carrier decides how those calls reach the public switched telephone network (PSTN) ¹, what caller ID is allowed, and how emergency calls behave. Once I understand this boundary, choosing carriers, reading SIP errors, and planning failover becomes much easier.

After that, the PBX becomes just one side of a partnership. The carrier gives me trunks, DIDs, and routing, and I bring a stable SIP edge, clean dial plans, and clear policies. Together, they form the “voice backbone” that sits under every intercom, IP phone, and call path in my projects.

How do I choose between ITSPs and PRI providers?

Many teams keep old PRI lines “because they are reliable” while also paying for SIP trunks, so they end up funding two worlds at once.

I choose between ITSPs (SIP carriers) and PRI providers by looking at where my traffic lives, what hardware I already run, and how much flexibility I need for scaling and routing.

SIP ITSP vs PRI: what actually changes for me?

At a high level:

• A SIP carrier / ITSP sends calls over IP using SIP and RTP.
• A PRI / T1 / E1 provider sends calls over circuit-switched lines to a physical interface on my PBX or gateway.

From my PBX view, the main differences are:

If my environment is already IP-based, with SIP PBX, SIP intercoms, and remote users, SIP trunking ² is usually the natural fit. I get easier number management, more routing options, and simpler multi-site design.

PRI still has value in some cases:

• Remote or regulated sites where internet is weak or controlled.
• Legacy PBXs that speak Primary Rate Interface (PRI) ³ natively and would need expensive upgrades.
• Environments where someone else already paid for private voice circuits and they still work well.

In mixed designs, I often see:

• SIP trunks as the main carrier path.
• PRI as backup or for specific legacy integrations.

For a new build that also uses SIP intercoms and IP paging (like we often deploy), going “all SIP” with at least one strong ITSP usually keeps the design simpler and cheaper over time.

Which SLAs and codecs should my carrier support?

Two carriers can have the same price and DID range, but one gives stable low-jitter audio and fast support, while the other drops calls during busy hours.

I look for SLAs that cover uptime, latency, and support response, and I expect my carrier to support at least G.711 plus clear rules for any compressed or wideband codecs.

What SLAs matter beyond “99.9% up”?

Marketing pages love big uptime numbers, but I focus on details that affect real calls. A written service level agreement (SLA) ⁴ matters most when it spells out what happens during partial outages and degraded performance, not just full downtime.

For many SMB deployments, these things are “best effort”. For critical sites (hospitals, industry, security control rooms), I want written targets and a clear escalation path.

I also check POP diversity. If the carrier has multiple points of presence (POPs) ⁵ and smart routing, they can keep voice up even if one region has trouble. That matters a lot when I carry intercom and emergency traffic over the same trunks.

Codec expectations and media interop

Codecs decide how audio is encoded between my PBX and the carrier. I keep the list short and clear:

• G.711 (A-law or μ-law) ⁶: baseline narrowband, almost always supported.
• G.729: compressed narrowband for low-bandwidth links, if needed.
• Opus or G.722: for wideband / HD voice, if both sides support it.

From a carrier, I expect:

• Clean support for G.711 without forced transcoding.
• Clear documentation on any supported compressed codecs.
• A known stance on T.38 or other fax handling if I still carry fax.

Inside my PBX, I prefer to normalize codecs:

• Use G.711 on trunks, wideband internally if I want better quality.
• Avoid transcoding whenever possible, since it adds CPU load and delay.

When we deploy SIP intercoms, emergency phones, and paging endpoints, stable G.711 on trunks is usually enough. Low jitter and low packet loss matter more than fancy codecs for those scenarios.

Can I use multi-carrier failover and least cost routing?

Relying on a single upstream is the fastest way to turn a carrier outage into a business outage. At the same time, managing multiple carriers feels complex without a plan.

Yes. My PBX or SBC can use multiple carriers for failover and least cost routing (LCR), as long as I normalize dial plans and caller IDs and keep routing logic simple and visible.

How multi-carrier failover usually works

The idea is simple: if Carrier A fails, I send calls through Carrier B. The detail lives in routing:

• On the PBX or SBC, I define outbound routes by pattern (for example, local, national, international).
• For each route, I list primary and backup carriers.
• If the primary trunk fails registration or rejects calls with certain codes (like 503), the PBX tries the next carrier.

A simple mapping:

For inbound failover, the carrier side must help:

• Many carriers can fail incoming DIDs over to another SIP URI or PSTN number if your main PBX is down.
• Some allow per-DID or per-location failover rules, which is very useful for emergency phones and intercoms at remote sites.

Least cost routing without breaking quality

Least cost routing (LCR) ⁷ chooses the cheapest available path, but chasing the lowest rate at all costs can hurt reliability. So I treat LCR like this:

1. Define tiers of carriers based on both price and quality.
2. Use the cheapest carrier inside the top quality tier for each destination.
3. Only fall back to lower tiers or “budget” routes when I understand the trade-offs.

A small example:

I might route:

• EU landline via ITSP A (best quality and fair rate).
• US domestic via ITSP B (cheaper and still stable).
• Avoid ITSP C except for non-critical calls or specific testing.

Because we often run emergency phones and SIP intercom traffic over the same PBX, I never send those calls through “promo” routes. Cheap but unstable is not a good trade when someone presses a red emergency button at a door station.

Why does my carrier reject calls with 403 or 488?

From the user’s view, a rejected call “does not work”. From the PBX’s view, 403 and 488 actually tell you why the carrier refused it.

Carriers return 403 for forbidden or unauthorized calls (often caller ID or permissions), and 488 when they cannot accept the media or SDP you offered, such as unsupported codecs or formats.

SIP 403 Forbidden: policy or authentication problem

A 403 Forbidden usually means “I see your request, but I will not complete this call.” Common reasons:

• Outbound caller ID is not allowed (number not on your account).
• Number format does not match what the carrier expects.
• Destination is blocked by policy (country, premium, or special codes).
• Your IP is not authorized for this trunk.

A simple troubleshooting table:

First step is to capture a SIP trace and confirm:

• What caller ID you send in From and P-Asserted-Identity.
• What dialed number format you send (with or without country code).

Then I match those to what the carrier expects. Often the fix is:

• Send caller IDs in E.164 that are registered to your account.
• Strip or add country codes as the carrier requires.
• Ask the carrier to enable certain prefixes if your contract allows them.

SIP 488 Not Acceptable Here: media or SDP mismatch

A 488 Not Acceptable Here says “I see your call, but I cannot accept the media you proposed.” Typical causes:

• Codec mismatch: you offer only codecs the carrier does not support.
• You try wideband or exotic codecs where the carrier expects G.711.
• Bad SDP formatting, missing RTP ports, or strange media attributes.
• SRTP or encryption flags that the carrier does not understand.

Here I check:

• The codec list my PBX offers on that trunk.
• Whether I am forcing something like Opus or G.722-only on a trunk that wants G.711.
• RTP port ranges and any firewall or NAT that might strip or change SDP.

A quick alignment strategy:

If 488 appears only when a call involves video or special media (like some SIP door phones), I might need to:

• Strip video for external trunks and keep it inside the LAN.
• Use a transcoding SBC that can map between device codecs and carrier codecs.

When 403 and 488 are understood as clear signals, not random failures, troubleshooting becomes much faster. The PBX owns the dial plan and media offer; the carrier enforces policy and capabilities. Getting them to agree is the real work.

Conclusion

Once I see the carrier as my controlled edge to the public network—rather than a black box—choosing SIP vs PRI, tuning SLAs and codecs, using multi-carrier routing, and decoding 403/488 rejections all become normal design tasks instead of mysteries.

Footnotes