The Telephony Network as a Multi-Leg Relay Race
The Telephony Network as a Multi-Leg Relay Race
by Alexander Conroy
Understanding why certain call information, like the presence of a third party, is invisible to a downstream carrier requires viewing the telephone network as a high-stakes, multi-leg relay race.
In this model, each carrier, platform, or even an internal enterprise phone system represents a runner responsible for a specific segment of the call.
In this model, each carrier, platform, or even an internal enterprise phone system represents a runner responsible for a specific segment of the call.
The Core Principle: The Run is a Black Box
The fundamental rule of this network analogy is that the running process itself is private.
- The Runner’s Process: When the runner before you is on their leg, you do not follow them to see how they manage their part of the track. If they internally add another person to their call—which is akin to picking up an extra item during their run—that process is confined to their system.
- The Goal is the Hand-Off: All that matters to the next runner is receiving the baton when the previous runner completes their segment.
- The Baton is the Unified Connection: The “baton” is the single, completed voice connection and the associated basic signaling data (such as the Caller ID).
The Invisibility of the Third Party
When a client adds a third party to a call, they are doing so during their platform’s “run.” This explains the impossibility of downstream detection:
- Merger Before Hand-Off: The voices of the client and the third party are immediately merged into a single audio stream within the client’s system before the call is handed off to the next upstream carrier.
- The Single Baton: The upstream carrier receives one baton (one unified connection). That carrier, in turn, passes that single baton to the downstream platform.
- No History Attached: The downstream platform receives the connection identifying only the immediate source (the carrier that handed off the baton). It does not receive a complete log or history of who was connected during the upstream carrier’s “run.”
Information Isolation is Symmetrical
This principle of isolation is not one-sided; it governs the entire network:
- Downstream Blindness: The final receiving platform cannot look backward to inspect or control a third party who was added at the call’s point of origin. The third party’s voice is indistinguishable from the main party’s voice within the single audio stream received.
- Upstream Blindness: Similarly, the originating party (the client) cannot look forward to see what the final carrier is doing—for example, if the final carrier added a recording function or connected another hidden party to their conference.
The inability to detect or remove a third party on an inbound leg is not a technical limitation of the platform, but a fundamental architecture of the telecommunications network where visibility is limited exclusively to the immediate connection segments. You only receive the baton, and nothing more.
If all call parties were connected to the same exact system, and in a single conference, then yes, you could forcibly eject people from the conference as needed. But since most third-party vendors won’t run on your platform and have their own for tracking and other purposes, whatever they do on their platform you have no visibility on because that’s their run on the relay race.
If the telephone system would transfer the entire conference into your system, then that would theoretically be possible, but there is no protocol for transferring a conference from one system to another as it would require multiple channels to be established for a single call. This is not standard in telephony at all outside of internal systems once the call arrives. It would almost be like taking multiple inbound one from the vendor and one from the client. But this would have to be done purely upstream, even if it was theoretically possible.
So as an example for those people who generate outbound calls and turn them into transfers and then transfer them into something like Ringba or Retreaver:
- The first leg is the fronter to the client conference. The fronter may also have a recording channel in the conference or a third party or manager listening.
- The second leg is the outbound call using a spoofed number to represent the client’s phone number to the call routing platform like Retreaver or Ringba. This creates another conference with the fronters system, which still needs to stay connected for the call to continue otherwise it will drop. It can also include its own recording.
- Then the third leg is our system which receives another spoofed outbound call with the Caller ID of the original client, but the connection is between Ringba or Retreaver and our system not the client directly. Then we merge that call into the agents conference, which includes a recording channel.
So each step of the way doesn’t have visibility as to the previous stuff that’s happened outside of the phone number that’s being passed and a single channel of audio that needs to maintain itself open for it to continue because the client is technically still connected to the origination point of the fronter.
So if you were to disconnect the fronters system, you would effectively kill the entire call because you broke the chain. Relay race over. The runner fell and failed and the baton never continued to get passed.
This is also why you’ll notice drop calls from certain vendors that have misconfigured maximum call and conference times as well as poorly trained agents that end up hanging up on the conference instead of leaving the conference so it stays active.
This is the equivalent of what the leave transfer button does in TLD. It leaves the client in the conference room with the third-party in the conference room, but it removes the agent so they can get into a new conference room and receive another call and continue working. Even though there is no agent on the line the call is still active and recording!
And the funny thing?
The Telco carriers are charging everybody along the way.
- The client gets charged for the phone call from the fronter.
- The fronter gets charged for the phone call to the client.
- The fronter is charged for the call to the call router.
- The call router is charged for the inbound call from the fronter.
- The call router is charged for the call to our platform.
- We are charged for the call from the call router, which is the only fee that the client pays directly.
Crazy isn’t it?
That’s 6 different minute rate charges along the way.
This also means that between the client and the fronter or the fronter and the call router or the call router and the platform, there are intermediary carriers that provide the paths to continue the stream that almost no one knows who is being used and the same call may go over a different set of routes at a different time. (Unless going SIP Direct from one platform to another which is why it’s recommended ). This can even affect deliverability.
This explains why in telephony you usually have people that have “clean routes” which is why we use Telnyx.
In some cases you can have one call go through as spam likely and then another one not go through as spam likely but with the same Caller ID because it simply went through a different route and one of the carriers flagged you along the way.