How a business call actually travels, hop by hop.

The short version

A customer dials a ten-digit number printed on a van. A few seconds later a technician's mobile rings in a truck two towns away, showing the customer's own number. To the customer it was "just a phone call". In fact the call crossed numbering databases that no single company controls, was handed between carriers that have never met either party, was very likely converted from one audio format to another, was cryptographically signed somewhere along the way, and was turned into a second, separate call before it reached the mobile.

This piece walks that path in order, citing for each step the body that defines it. Where a piece of the path is proprietary, we describe only what its owner says publicly.

The whole path on one page

The scenario throughout: a caller on any phone dials a business's local number. The number is held by a provider that answers with a phone menu. The caller presses 2, and the call is forwarded to a team member's ordinary mobile on a different carrier. The numbers in brackets are the sections below.

CALLER'S PHONE (mobile, landline or VoIP)
   |  dials 613-555-0100
   v
CALLER'S CARRIER  (originating switch / IMS core)
   |  [1] digits read as NPA-NXX-XXXX under the NANP
   |  [2] routing data: which carrier and switch hold that block
   |  [3] portability: has the number moved? local NPAC-fed copy -> LRN
   |  [8] STIR/SHAKEN: originating carrier signs the caller ID
   v
[5] SBC ---- [4] SIP INVITE + SDP offer ----> ( transit carrier[s], each with SBCs )
                                                  |
                                                  v
                                   BUSINESS NUMBER'S PROVIDER  [5] SBC
                                    [4] 100 Trying, 200 OK, SDP answer
                                    [6] RTP audio flows (G.711, AMR-WB, Opus ...)
                                    [7] caller presses 2 -> RFC 4733 DTMF event
                                   [10] starts a NEW call leg (B2BUA):
                                        From = the original caller's number
                                        Identity headers: original + "div"
                                                  |
                                                  v
                                    [3] portability query again, for the MOBILE
                                                  |
                                                  v
                                   TEAM MEMBER'S MOBILE CARRIER  [5] SBC / IMS
                                    [8] verifies the signature
                                    [9] looks up the caller's name (CNAM)
                                    [6] pages the handset; VoLTE audio in AMR-WB
                                                  |
                                                  v
                                   TEAM MEMBER'S MOBILE RINGS
                                   showing the caller's number

Audio, once both legs answer:            [11] delay and one-way audio live here
CALLER <==RTP==> [media relays / transcoders] <==RTP==> MOBILE

Two things here surprise most people. Signalling (who is calling whom) and media (the audio packets) are separate flows that may take different routes. And forwarding is not the original call bending round a corner: it is a new call, placed by the business's provider and joined to the first in the middle.

1. The dialled number: what ten digits encode

The United States and Canada share one numbering plan. The North American Numbering Plan (NANP) is "an integrated telephone numbering plan serving 20 North American countries that share its resources", including the United States and its territories, Canada, Bermuda and much of the Caribbean.1 Its numbers are "ten-digit numbers consisting of a three-digit Numbering Plan Area (NPA) code, commonly called an area code, followed by a seven-digit local number", written "NXX-NXX-XXXX where N is any digit from 2 through 9 and X is any digit from 0 through 9".1 The ITU assigned the whole NANP country code 1.1

The six leading digits, NPA plus the central office code (NXX), historically told the network everything. The portability database operator puts it plainly: "Calls are routed based on the first six digits (NPA-NXX) of the telephone number. The NPA-NXX is the address of the switch serving the telephone number."2

Administration is split by country. NANPA "holds overall responsibility for the neutral administration of NANP numbering resources" and is the national administrator for the US; "COMsolve Inc. serves as the Canadian Numbering Administrator".1 NANPA also stresses that it "is not a policy-making entity": the FCC and, in Canada, the CRTC set the rules.1 Our area-code reference lists every US and Canadian code from those administrators.

2. Routing data: who holds the number block

Knowing that 613-555 is an Ottawa-area block does not tell a carrier in Texas where to send the call. For that, carriers rely on routing reference data. The best-known compilation is the LERG Routing Guide, a commercial product. It is proprietary and sold by subscription, so we describe only what its publisher says on its public product page.

According to that page, the LERG "contains current information about the local Public Switched Telephone Network (PSTN) as well as additional information about IP Networks and includes scheduled future activity".3 It was "initially designed for the routing of Inter-Local Access and Transport Area calls" by long-distance carriers and now serves CLECs, wireless providers, ISPs and VoIP providers.3 The listed contents include operating company numbers, area codes, "NPA NXX Thousands-Blocks assignments for the United States and its territories, Canada, Bermuda, and 16 Caribbean countries", switch records, "Switch Homing Arrangements (tandem and other switch-to-switch interconnections)", rate centres, and Location Routing Numbers.3 It is "Produced: first workday monthly", with optional daily change files for subscribers.3

Older material calls the LERG an iconectiv product; its pages now carry Transaction Network Services (TNS) branding.3 We found no public statement explaining the change. What routing data cannot tell a carrier is whether this particular number has since moved. That is the next step.

3. The portability query: has this number moved?

When a business ports its number to a new provider (see porting your number), the number keeps its NPA-NXX, but the switch that serves it changes. The fix the industry chose in the 1990s is the Location Routing Number (LRN): "a ten-digit number designed to look like a telephone number", which is "assigned to each ported telephone number and is used to route calls through the PSTN to the switch serving the ported number".2 "Calls to the ported number are instead routed based on the NPA-NXX of the 10 digit LRN."2 The LRN method, developed by AT&T and Lucent, "became the de facto industry standard and later was adopted by the Federal Communications Commission in 1997".4

The call-time mechanics, in the operator's own words: "the initiating service provider switch launches a query to its LNP call routing database to determine whether the telephone number has been ported. If it has, the database response provides the switch with the LRN needed to properly route the call. If the number is not ported, the database response indicates that the call should be routed based on the telephone number."2 Note "its" database: carriers query their own copy, fed from the central system, not the central system itself on every call.

US rules make the responsibility explicit. The "N-1" carrier, the one before the carrier terminating the call, "is responsible for ensuring number portability queries are performed on a N-1 basis where 'N' is the entity terminating the call to the end user ... unless another carrier has already performed the query".5 A terminating carrier that receives an unqueried call "may block the unqueried call only if performing the database query is likely to impair network reliability".5

The central system is the Number Portability Administration Center (NPAC). Historically, "Eight regional LNP databases were established, the seven U.S. databases coinciding with the seven original Regional Bell Operating Company regions and a single database to serve Canada."4 Each NPAC record holds the number, the current provider's ID, the provider type (wireless or wireline), the LRN, and SS7 point codes for services including CNAM.2 When a port activates, the record is "broadcast to the telecommunications industry network within milli-seconds", according to the Canadian NPAC's operator.2

In our scenario the portability lookup happens twice: once for the business number on the inbound leg, and again for the team member's mobile number on the forwarded leg, because mobile numbers port between carriers too.

4. Into SIP: the INVITE and its answers

Somewhere between the caller's carrier and the business's provider the call is almost certainly carried as SIP. Some carriers still hand calls to each other over older circuit-switched trunks with SS7 signalling; US rules still spell out what must be sent "in the SS7 ISUP (ISDN User Part) CPN field" as well as in "Session Initiation Protocol (SIP) header fields".8 Hosted business phone platforms, in our experience, speak SIP throughout.

SIP is "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants", including "Internet telephone calls".9 It does not carry the audio. It carries the setup conversation, in text messages that look a lot like HTTP:

• INVITE: the request to set up a call, carrying a description of the media the caller can handle.
• 100 Trying: "the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted)". It is hop-by-hop and "never forwarded upstream by a stateful proxy".9
• 180 Ringing: "The UA receiving the INVITE is trying to alert the user", and it "MAY be used to initiate local ringback".9 183 Session Progress conveys other progress information.9 Audio sent before the call is accepted is called early media, and its "Typical examples ... are ringing tone and announcements".10
• 200 OK: the call is answered, carrying the answering side's media description. The caller confirms with an ACK.9

The media negotiation inside those messages is the SDP offer/answer model. The offer lists "the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media"; the answerer replies with "a matching media stream for each stream in the offer".11 Remember that "addresses ... to receive the media" detail: it is the root of the one-way-audio problem below.

An illustrative INVITE as it might arrive at the business's provider (example addresses and numbers; not captured from any real network):

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 203.0.113.10;branch=z9hG4bK74bf9
From: <sip:[email protected]>;tag=9fxced76sl
To: <sip:[email protected]>
P-Asserted-Identity: <sip:[email protected];user=phone>
Identity: eyJhbGciOiJFUzI1NiIs...;info=<https://cert.carrier.example/sti.pem>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Type: application/sdp

v=0
o=- 2890844526 2890844526 IN IP4 203.0.113.20
s=-
c=IN IP4 203.0.113.20
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Read it top to bottom: who is called, who is calling (twice: the user-visible From and the network-asserted identity), a signature over the caller ID (the Identity header, section 8 below), and an offer of G.711 in its two variants plus DTMF events, to be received at 203.0.113.20 port 49170. P-Asserted-Identity lets "a network of trusted SIP servers ... assert the identity of authenticated users", but only "inside an administrative domain with previously agreed-upon policies".12 In other words, it is a promise between parties who trust each other, not proof.

RFC 3261 also describes how a proxy can send one INVITE "to a number of locations at the same time. This type of parallel search is known as forking."9 Forking is one way "ring all phones" can be built inside one provider's network.

5. Session border controllers: the customs posts

Carriers rarely let SIP from another network touch their core directly. At each boundary sits a session border controller (SBC). Formally, SBCs are one kind of back-to-back user agent (B2BUA), "the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC)": they terminate the call on one side and originate a matching call on the other.13 IP PBXs and application servers are B2BUAs too.13

The IETF's description of what SBCs do in practice is unusually candid, because many of those functions bend SIP's original design:14

• Topology hiding: rewriting headers so that the other network cannot see the internal addresses.
• Media traffic management: "By modifying the session description, the SBC can force the media to be sent through a media relay", for example to ensure quality or enforce allowed codecs. "Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description."
• Fixing capability mismatches: connecting endpoints "that support different IP versions, different codecs, or that are in different address realms". The RFC calls this "a fragile function in the long term".
• NAT traversal and access control: keeping connections to devices behind home and office routers alive, and filtering who may send calls.

A forwarded business call can easily cross four or more of these boxes: out of the caller's carrier, into and out of any transit carrier, into the business's provider and out again, and into the mobile carrier. Each is a place where a header can be rewritten, a codec swapped or an audio stream re-anchored. This is a large part of why identical calls can behave differently depending on which carriers they touch.

6. The audio itself: RTP and codecs

Once the call is answered, audio flows as RTP packets. RTP "provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio", but "does not address resource reservation and does not guarantee quality-of-service".15 It typically rides on UDP, with a companion control protocol (RTCP) for reception statistics.15 Lost packets are not retransmitted; the receiving side conceals the gap and moves on.

For packetised audio, the default packetisation interval "SHOULD have a duration of 20 ms or one frame, whichever is longer"; the interval "determines the minimum end-to-end delay".16 So roughly fifty packets a second flow in each direction.

Three codecs matter for this path:

Scroll the table sideways to see every column.

When the two ends share no codec, something in the middle transcodes: SBCs and media gateways decode one format and re-encode another.14 A mobile caller in AMR-WB, over a G.711 interconnect, to a softphone in Opus, is transcoded at least twice, and each pass adds delay and loses quality. Once wideband audio has been squeezed through narrowband G.711, the lost bandwidth does not come back.

We think this is the most under-appreciated quality factor in business calling. "HD voice" exists end to end only when every leg and every interconnect agrees on a wideband codec, and the business owner usually controls none of those negotiations.

7. Pressing 2: how a key press crosses an IP network

A phone menu depends on the caller's key presses arriving intact. On the old network they were audible tones (DTMF). On an IP path, sending them as sound inside the voice stream is fragile: RFC 4733 explains that separate formats are needed "since low-rate voice codecs cannot be guaranteed to reproduce these tone signals accurately enough for automatic recognition".21

So the standard approach is to send key presses as events: small RTP packets that say "digit 2, started at this time, lasting this long", using the telephone-event payload type negotiated in the SDP (payload 101 in the example above).21 The format also "permits higher redundancy while maintaining a low bit rate": event packets are typically repeated, so a single lost packet does not swallow a digit.21 Mobile networks support this too: the voice-over-LTE profile says "The UE and the IMS core network must support DTMF events".20

Where it goes wrong is at boundaries. If one leg negotiated events and another did not, a gateway must convert between events and audible tones, and if nobody converts, the menu hears nothing. In our experience this is the usual cause of the complaint "the menu doesn't respond when customers press a number", and it is why we think a provider should test DTMF across each carrier it interconnects with.

8. STIR/SHAKEN: signing the caller ID on the way

Caller ID in SIP is just a header the originating network writes. STIR/SHAKEN adds a signature. The IETF mechanism defines "a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer" (the Identity header in our example).22 The SHAKEN profile adds three attestation levels: "full attestation when the service provider can fully attest to the calling identity, a partial attestation when the service provider originated a telephone call but cannot fully attest to the calling identity, and a gateway attestation" for calls received from a gateway that does not support it.23

In the US, by 30 June 2021 voice service providers had to "fully implement the STIR/SHAKEN authentication framework in its internet Protocol networks", authenticating calls they originate and verifying calls they terminate.24 The framework only works on SIP; for non-IP networks, the rule allowed providers instead to document participation in work on a "non-internet Protocol caller identification authentication solution".25 Any circuit-switched segment in the middle of a call therefore drops the signature. In Canada, the CRTC directed providers to implement STIR/SHAKEN "for Internet Protocol (IP)-based voice calls as a condition of offering and providing telecommunications services, effective 30 November 2021".26

Attestation in depth, handset display and spam labelling are a subject of their own; the forwarding wrinkle is in section 10.

9. The name on the screen: CNAM is looked up, not sent

The number travels with the call. In the United States, the name usually does not. A vendor's support documentation describes the mechanism clearly: "When the recipient receives a call, their carrier is responsible for displaying the assigned caller name by querying the appropriate databases containing CNAM data entries. These databases are known as CNAM repositories and collectively referred to as the Line Information Database (LIDB)."27 Carriers "may subscribe to one or more of the CNAM databases and perform lookups, also known as 'dips'".27

Three consequences follow. The name is at most 15 characters, conventionally in capitals.27 The terminating carrier may have stale data or subscribe to a different database from the one your provider updated.27 And on mobiles, the name may not be shown at all unless the recipient's plan includes it: "Mobile users in the US may need to subscribe with their carrier for CNAM to be displayed".27 A name saved in the recipient's own contacts is not CNAM at all.

We could not find a first-party source describing how Canadian carriers deliver calling name, so this section describes the US only.

10. The forwarding leg: a second call wearing the first caller's number

Here is the step that makes a forwarded business call different from an ordinary one. When the caller presses 2, the business's provider does not "pass the call along". Acting as a B2BUA, it places a brand-new outbound call to the team member's mobile number and joins the two legs.13 That new call goes through sections 2 to 9 all over again: routing data, a portability query on the mobile number, interconnects, SBCs, a signature, the mobile carrier's lookups.

The provider chooses what to put in the new leg's From and asserted-identity headers. The convention for forwarding, and what most people want, is to present the original caller's number, so the technician sees who is calling before answering. US rules require providers in the path to transmit the calling number, and intermediate providers to "pass unaltered to subsequent providers in the call path signaling information identifying the telephone number ... of the calling party", explicitly including "Session Initiation Protocol (SIP) header fields".8 (Whether a given forwarding service is acting as an intermediate provider or originating a new call for regulatory purposes is a classification question we do not try to answer here.)

The original destination can be recorded too, in History-Info, which captures "how and why a SIP request arrives at a specific application or user",28 or in the historic Diversion header, "still used for this purpose by some operators today".29 Neither shows on a normal mobile screen.

Forwarding creates a problem for caller-ID signatures. A STIR signature covers the called number as well as the caller, precisely so that it cannot be cut and pasted onto a different call. A forwarded call arrives at a number that is not the one the caller dialled, which looks exactly like that attack. The IETF's answer is the "div" PASSporT: the forwarding provider adds a second signed token in which the original "dest" becomes the "div" claim, the new target becomes the "dest", and the "orig" (the caller) "MUST be copied into the new PASSporT from the original".29 The mobile carrier can then check both signatures and see a legitimate redirection. We could not find a public source measuring how widely US or Canadian terminating carriers verify "div" tokens today, so we make no claim about deployment.

11. Where delay and one-way audio come from

Delay. The ITU's planning guidance is that if one-way, mouth-to-ear delay "can be kept below" 150 ms, "most applications, both speech and non-speech, will experience essentially transparent interactivity", and that "it is recommended to not exceed a one-way delay of 400 ms for general network planning".30 The budget fills from several places:

• Distance. Optical fibre adds about 5 µs per kilometre.30 On our arithmetic, 4,000 km of fibre (roughly a Montreal to Vancouver route) costs about 20 ms one way.
• Packetisation. Each 20 ms packet of audio must be filled before it is sent.16
• Codecs. Encoders have their own look-ahead; for Opus, between 5 ms and 65.2 ms depending on mode.18
• Jitter buffers. Receivers deliberately "impose a playout delay" to smooth uneven packet arrival.21
• Every transcode and media relay. Each one decodes, buffers and re-encodes.14

A forwarded call pays several of these twice, once per leg, plus the radio access delay on the mobile side. That is why a forwarded call routed through a data centre far from both parties can feel slightly "laggy" when a direct mobile-to-mobile call does not.

One-way audio is a different failure, and almost always an addressing problem. The SDP offer and answer each say where that side wants to receive audio.11 A device behind a home or office router (a NAT) may put its private, internal address in its SDP. The far end dutifully sends audio to an address it cannot reach, while the device's own outgoing audio gets out fine. One side hears the other; the other hears silence. The IETF notes that sessions exchanging IP addresses and ports face "challenges when operated through Network Address Translators" and that the various fixes each work "in some network topologies, but a poor choice in others".31 Softphones use ICE to test candidate addresses before media starts;31 carriers' SBCs instead rewrite the SDP and "force traffic to go through a media relay for NAT traversal purposes", sometimes relaying only one direction.14 In our experience, when one-way audio appears on calls to a mobile, the usual suspects are a softphone or desk phone on a misconfigured office network, or a media relay that one leg failed to pass through.

12. Where 911 is different

Everything above concerns ordinary calls, routed by number. Emergency calls are routed by location, over separate infrastructure, to a public safety answering point (PSAP).

• Interconnected VoIP, US. Providers must send 911 calls, the caller's number (ANI) and location to "the PSAP ... that serves the caller's dispatchable location", and "All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network"; the location must be available to the PSAP through the "automatic location information (ALI) database".32
• Mobile, US. Mobile carriers must "transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point".33
• Canada. The CRTC requires local VoIP providers to provide "either Basic or Enhanced 9-1-1 service", to tell customers of any limitations, and points providers to its next-generation 9-1-1 decision.34

For our scenario this has a practical meaning. A forwarding service sits only in the inbound path. When the team member dials 911 from the mobile, that call is the mobile carrier's, under the mobile rules, and never touches the business number's provider. A caller who hangs up and dials 911 is likewise handled by their own carrier. The business's phone menu is simply not in the emergency path, which is one reason we think a mobile-first setup is easier to reason about than a desk-phone PBX. Our emergency calling page sets out Kari's Law and the dispatchable-location rules in full, with the Canadian 9-1-1 rules.

Our view: a dozen companies behind one ring

Count the independent organisations in a single forwarded call. The caller's carrier. Possibly one or more transit carriers. The numbering administrators (NANPA, or COMsolve in Canada). The routing data publisher. The portability administrator (iconectiv in the US, Neustar in Canada) and the local copies each carrier keeps. The business number's provider. Its upstream carrier, if it is not one itself. The policy administrator and certificate authorities behind STIR/SHAKEN.24 One or more CNAM databases. The team member's mobile carrier. That is roughly a dozen, before counting the vendors whose SBC and media-gateway software runs at each boundary.

We think this matters for reliability in three ways.

1. Failures are usually at the joins, not in the boxes. Each organisation tests its own system. The common business-calling faults (digits not recognised, one-way audio, the wrong name, a forwarded call labelled as suspicious) arise where two networks' assumptions meet: a DTMF mode, an SDP address, a database one side has and the other does not subscribe to, a signature that did not survive a hop.
2. The business owner holds one contract. When a call fails, the only party with a duty to the business is the provider it pays. A good provider can trace a call across its interconnects using Call-IDs and timestamps; a weak one says "it must be the other carrier". Ask which one you are buying before you need it.
3. Forwarding doubles the exposure. A forwarded call is two calls, each crossing its own chain. The convenience of ringing ordinary mobiles is real, and it is the model our own service is built around. But it means the inbound leg and the outbound leg both have to work, and a provider should be able to show you how it monitors both.

Questions worth asking any business phone provider, in writing: Which codecs do you negotiate on calls to mobiles, and where do you transcode? Do you send DTMF as RFC 4733 events, and do you convert where a carrier does not? Whose number appears on a forwarded call, and do you sign forwarded calls with a "div" token? Who updates the CNAM for my number, and in which databases? What happens to a call if your upstream carrier has an outage? An honest provider will answer each of these specifically, including "we don't know" where that is the truth.