How It Works
Each call always has at least two parties: one that is calling and the other one (or more than one) that is receiving the call. CarrierX allows its users to call from a landline or mobile phone and connect to a SIP phone, SIP server, office PBX, etc. In a word, to almost any device that can send or receive voice calls.
Let’s see how the calls between regular phones are routed and what CarrierX changes in this flow.
Calling between Two Regular Phones
A long-long time ago, even before the internet, all the phones were connected using the copper wire. A phone normally needed a direct wired connection to another phone or to a telephone switch (or central office), which routed all the calls to other phones.
This connection was physical, and it was called POTS (plain old telephone service). First connections between several phones were routed manually, with the help of human telephone operators. Later, automatic switches appeared, and all the phones and these switches were aggregated into world circuit-switched telephone networks, called PSTNs—public switched telephone networks. Yet still this system was mostly analog.
Digitalization brought new possibilities. Together with the automation of telephone switches, phone lines were upgraded and now carry digital signals in the form of packets. But even with these possibilities, the last mile between the telephone service provider and the landline phone remains analog in most cases.
The PSTN remains the network of the copper phone lines. It is a circuit-switched network, and it requires a physical connection between two points—two phone numbers—to complete a call. You cannot dial a computer IP address from such a phone to connect to a VoIP application.
Calling from a Regular Phone
DIDs are a part of CarrierX infrastructure. These virtual phone numbers allow callers to dial them and connect to VoIP applications (CarrierX based or hosted by partners) without even knowing they do that. Regular phones call the DIDs like they do with other regular phones, dialing a phone number. Most often this DID number is located in the same geographical region with the regular phones, so the caller just makes a usual local phone call, but is connected, for example, to a SIP phone, a PBX, or to another regular phone.
Such a call starts with dialing a number using a landline phone. This call goes through the PSTN using the wired or mobile connection.
When the call reaches the PSTN, it is then routed to a CarrierX DID, just the way it is usually routed to another regular phone.
That’s where the magic begins.
CarrierX DIDs hand the calls over to trunk groups. Think of a trunk group as of a highway with many lanes going in different directions, each to its own destination and each holding many vehicles. These lanes are trunks, and the vehicles are your calls.
DIDs are associated with trunk groups, and trunks are associated with endpoints. Thus, each DID processes your call and directs it to the right trunk group. The trunk group, in its turn, directs the call to the right trunk so that it could be forwarded to a correct destination—an endpoint, either hosted or a third-party one.
The endpoint routes the call to a representation of the phone on the other end of the line. This can be a software phone—a SIP phone developed by a third party, a voicemail, a set of instructions that processes an incoming phone call (answers it, turns on a recording with further instructions, or even hangs up); or this can be another regular phone or even several phones connected into a conference.
Calling from a Softphone
Calls going to regular phones are similar to calling from regular phones, the process just goes in reverse direction.
An external application needs to connect to a configured CarrierX endpoint first. This endpoint passes the control over to a trunk associated with it. The trunk directs the call to a DID associated with the trunk group. And then the call goes from the DID to the PSTN, and then to the regular phone (either landline or mobile).
Inbound vs. Outbound Calls
In CarrierX, inbound and outbound calls are differentiated by the direction of the call in relation to the rented DIDs.
When you call from a regular phone to a CarrierX DID, the DID accepts the call, so it is inbound for the DID.
When a CarrierX DID is the calling party, it initiates an outgoing connection, thus the call is outbound.
Conference, Conference Playback, and Voicemail endpoints always use inbound connections, the DIDs associated with them receive calls from regular phones.
FlexML, Mediator, and Third Party endpoints can have both inbound and outbound connections. You should bear this in mind when you use these types of endpoints with international calls, as such calls can cost more.
When speaking about telephony, you might quite often hear the following expressions: call legs, legA, legB. Let us explain what these terms mean.
When two phones connect, normally one phone is the initiator of the call, or the calling party, and the second phone is the recipient of the call, or the called party. As the phones do not connect directly to each other, but use a sort of a switch, there will be two paths for the call:
- one from the calling party to the switch,
- one from the switch to the called party.
These paths are called call legs:
As you can see in the figure above, the call leg that goes from the call originator (the calling party) to the switch is usually called legA. The second call leg (from the switch to the called party) is called legB.
The same is with CarrierX: when an application receives a call from a regular phone through a CarrierX DID, the line from that regular phone to CarrierX is legA, and the path from CarrierX to the application receiving the call is legB:
If we sum it up, call legs are the connections between the switch (in our case, the switch is represented by CarrierX infrastructure) and two parties:
- the calling party—legA, incoming connection, ingress—on the one side;
- the called party—legB, outgoing connection, egress—on the other side.
Read the following articles to get a better understanding of how things work in CarrierX: