CarrierX Endpoints

CarrierX endpoints are used as connection points between regular phones—both landline and mobile—and external applications representing various types of software phones. Applications hosted and developed by CarrierX, as well as third-party VoIP software, all use these endpoints to communicate with the users on the other side of the phone line. That is why endpoints are an important concept of the CarrierX API.

The endpoints provided by CarrierX can be subdivided into two major types:

1. Application endpoints.
   These are endpoints used for CarrierX hosted applications, and CarrierX provides an API to access them. They include
   • Conference endpoint;
   • Conference Playback endpoint;
   • FlexML endpoint;
   • Mediator endpoint;
   • Voicemail endpoint.
2. Third-party endpoints.
   These endpoints are suitable for connecting to third-party software or hardware SIP phones, as all the configuration is made on the application side, and the endpoint only provides an access point for connection of these applications to CarrierX infrastructure. The only endpoint of this type is
   • Third Party endpoint.

All of these endpoints can be connected to regular phones using CarrierX infrastructure.

Let’s take a closer look at all the main endpoint variations available through CarrierX.

Application Endpoints

Conference Endpoint

The Conference endpoint is used to host audio conferencing for up to 1,000 attendees. A hosted Conference application endpoint enables two or more parties to speak to one another.

Each Conference endpoint has meeting rooms—configurable objects that hold the settings for the meeting—associated with it. To access meeting rooms, access codes are used. The system uses the access codes to determine the access levels and the meeting room which the users will be connected to.

A typical call flow for a Conference endpoint will look like this:

Here, callers who have one of the access levels dial a phone number, then they are connected via the PSTN to a CarrierX DID, and then to the Conference endpoint via trunks in the trunk group associated with that particular endpoint.

At this point, the call is answered and the callers must enter their access codes. Depending on the entered access code, they are directed to a meeting room and are given access rights for the conference.

Conference Playback Endpoint

Conference Playback endpoints are used to listen to the saved recorded sessions made during conference meetings.

This is why a Conference Playback endpoint is not a completely standalone endpoint. It requires that you have a Conference endpoint created alongside with it and connecting these two endpoints with each other.

A typical call flow for a Conference Playback endpoint will look like this:

Here, a Conference endpoint should be created and connected to the Conference Playback endpoint. Refer to the Conference Playback Endpoint Quick Start for more information about how this can be done.

The participants call into a conference and make a recording of the session. The recording is saved into a file in the CarrierX storage.

As the Conference Playback endpoint now has access to that recording file, the users can dial the phone number associated with the Conference Playback endpoint. As with any other endpoint, they are connected via the PSTN to the CarrierX DID, and then to the Conference Playback endpoint via trunks in the trunk group associated with that particular endpoint.

The callers will hear the instructions for the recording playback and management.

FlexML Endpoint

FlexML endpoints are used to create instructions for voice workflows. These instructions use a simple markup language, which is operated with programmatic verbs such as Dial, Gather, Play, and many others. FlexML instructions can be used to manage inbound and outbound phone calls: add voice instructions for the caller, redirect calls to internal or external phone numbers or applications, hang up after certain actions are performed, etc.

A typical call flow for a FlexML endpoint with an inbound call will look like this:

Here, the caller dials a phone number, then they are connected via the PSTN to the CarrierX DID, and then to the FlexML endpoint via trunks in the trunk group associated with that particular endpoint.

The endpoint directs the call to the connected FlexML application, which then decides how to process the phone call depending on the instructions in it.

A FlexML endpoint with an outbound call looks almost the same, the call is originated by the FlexML application and directed to a regular phone (landline or mobile).

FlexML applications can be hosted both in CarrierX infrastructure and anywhere in the internet, the main thing is that it must be accessible by the FlexML endpoint.

Mediator Endpoint

The hosted Mediator Application endpoint acts as an intermediary between phone numbers. The service has two primary abilities:

• With bindings, incoming calls are routed through CarrierX to a destination phone number.
• In dialouts, the CarrierX system makes outgoing calls to two different parties, who are then brought into a call together.

Let’s take a look at both call flows more detailed.

Redirect from One Phone Number to Another

Here, a caller dials a phone number rented from CarrierX, then they are connected via the PSTN to the CarrierX DID, and then to the Mediator endpoint via trunks in the trunk group associated with that particular endpoint.

The endpoint uses a binding to redirect the incoming call to the destination phone number. This way, the caller will not know the callee phone number. It will be hidden behind the CarrierX DID that will serve for call forwarding.

Dial Two Numbers in Turns

This is done the following way: the dialout associated with the Mediator endpoint initiates a call that goes from a dialout via the endpoint, to trunks in the trunk group associated with the endpoint, then to the CarrierX DID, and to the stage one phone number via the PSTN. If the call is successfully answered, the same procedure is repeated for the stage two phone number. After both phones answer the call, they are finally connected together. Either phone number can be hidden from its calling counterpart, if necessary.

Voicemail Endpoint

The Voicemail endpoint is used to create a voicemail-like call flow: other callers dial your phone number and, if the call is not answered, they are redirected to the instructions allowing them to record their message. After that, you can check those recordings: listen to them, delete, get their transcriptions, etc. Refer to our Voicemail Endpoint Quick Start to get more information on how to set up and use Voicemail endpoint.

A typical call flow for a Voicemail endpoint will look like this:

Here, the caller dials a phone number, then they are connected via the PSTN to the CarrierX DID, and then to the Voicemail endpoint via trunks in the trunk group associated with that particular endpoint. The voicemail application, which is also hosted with CarrierX and associated with the endpoint, manages the incoming calls: whether to allow the callers to record their messages or to allow the phone number owner to listen to the recordings.

Third Party Endpoint

The Third Party endpoint call flow is not that different from all the above endpoint types. The main difference is that the application associated with the endpoint (where all the call processing takes place) is not hosted with CarrierX.

This way, the CarrierX third_party endpoint type is just a set of configs that allows the calling number to find and connect to your application, which will manage the call by its own means. For this, a Third Party endpoint on the CarrierX side needs to have the following information:

• The application public IP address, which must be accessible by the CarrierX Third Party endpoint;
• The application port (or it defaults to 5060), which must also be opened for the CarrierX Third Party endpoint;
• The transport protocol used by the application (tcp, tls, or udp).

A typical call flow for a Third Party endpoint will look like this:

Here, the caller dials a phone number, then they are connected via the PSTN to the CarrierX DID, and then to the Third Party endpoint via trunks in the trunk group associated with that particular endpoint. Once the endpoint is reached, it passes the control over the call flow to your application, which manages the call by itself from now on. This means that all the call data is sent to the application, and the application must be able to process the data.

A Third Party endpoint with an outbound call looks almost the same, the call is originated by your VoIP application and directed to a regular phone (landline or mobile).

Further Reading

Endpoint Object API Reference

Refer to the Endpoint object API reference to get the complete list of the endpoints attributes and methods used with the endpoints:

• Endpoint Object
• Create Endpoint
• Get Endpoints
• Update Endpoint
• Delete Endpoint

How It Works

Read the following articles to get a better understanding of how things work in CarrierX:

• Getting Started
• How It Works
• Trunk Groups and Trunks
• Prefix Routing
• Access Control
• Transformations
• STIR/SHAKEN
• Storing Files with CarrierX
• Send Push Notifications to Devices
• Lookup Phone Numbers and IP Addresses
• Using OAuth Tokens