Twilio

Twilio is a cloud based service that enables powerful communication between mobile devices, applications, services, and systems throughout the business in order to bridge the gap between conventional communication.

Twilio seeks to rid businesses of the messy telecom hardware by providing a telephony infrastructure web service via a globally available cloud API, allowing web developers to use standard web languages to integrate phone calls, text messages and IP voice communications into their web, mobile and traditional phone applications.

What Does Twilio Do?

We all interact with our phones every day. You can’t Go anywhere without them. And there’s a good chance that in one way or another you’ve interacted with a phone system that is powered by Twilio. However, since Twilio works in the background to bridge the gap between web-based applications and telephones, it can be hard to understand just how Twilio fits in the flow of customer communications.

What does Twilio actually do? And how does it do it? To answer those questions, we’ll first need a little bit of background on the world of telephony.

We’ll keep this discussion at a high level, but there are links to more in-depth information on some key concepts at the end of this article.

The telecom world

There’s an old network out there. Older than the internet. One that enables voice and SMS communications as we know it. This is the telephony network. While it is critical to world wide connectivity, this network runs in a relatively closed, slow-moving, and expensive ecosystem.

The telephony network is connected by carriers. Carriers are responsible for the flow of voice, text, and data all around the world. Carriers sell connections into their networks.

For you and me, that connection is simple: a cell phone or a home internet connection. Consumers are hidden from the complex world of languages, protocols, and hardware that goes into providing a global telephone network.

But for businesses, it’s not so simple. To build custom functionality on top of that connection, like a company phone system (PBX) or call center, many different additional pieces are required. Specialized servers and software are needed to do the work. Specialized facilities are needed to house and run the equipment. A specialized workforce is needed to install and maintain the equipment as well.

Imagine investing years of time and millions of dollars just to get set up. And if you want to change it? Prepare to invest even more time and money as you move to a new system.

Not every system speaks the same language

The telephony networks also run on a myriad of complex, and often proprietary, protocols. The internet largely communicates using a basic foundational protocol, HyperText Transport Protocol (HTTP).

The telephony networks make use of a diverse set of protocols, each one tailored specifically to the task at hand. Session Initiation Protocol (SIP) for managing real-time voice, video and messaging sessions. Extensible Messaging and Presence Protocol (XMPP), a specialized real-time messaging protocol (think IRC). Real-time Transport Protocol (RTP) for delivering voice and video over IP. Global System for Mobile Communications (GSM) to connect mobile devices.

That’s just to name a few. The list of protocols can be dizzying and the protocols themselves very complex. It’s not an easy task to implement these protocols.

How does Twilio solve the problem?

Twilio saw that the internet didn’t have nearly the same complexities found in the telephony network.

• There are oodles of developers because it is relatively easy to learn how to develop on the internet.
• There is a standard method of communication: HTTP.
• The internet is programming-language agnostic. Developers can write their applications in a familiar language.
• Capital costs are very low due to the existence of Platforms as a Service (PaaS). Deployment costs start low and scale as the company grows.
• Switching is much easier and more commonplace. The cost of trying a different service or technology is very low.

But there was a huge barrier: the internet was not connected to the telephony network.

Twilio sees its place in between these two networks. Twilio does the hard work of providing a bridge between the carriers and the internet. Developers can write software that can be deployed where it’s cheap and easy to learn. And Twilio can enable that software to interoperate with the highly specialized carrier ecosystem.

But Twilio doesn’t actually live in the gap between the internet and telecom. Twilio deploys all its infrastructure on the internet. Using dedicated connections to the carriers, Twilio bridges the worlds of internet and telephony.

It all starts with the phone number

The magic of being able to communicate with the telephony network is built upon the ability to target communications to a particular device. As we are all familiar, every mobile phone has a phone number that uniquely identifies that device. A Twilio phone number provides a virtual presence on the physical telephony network.

Twilio acquires and quality tests large blocks of phone numbers from carriers and number providers around the world. Twilio has dedicated teams and patented processes all dedicated to the management of its phone number inventory.

Twilio customers can search Twilio’s phone number inventory to find one that fits their use case – be it by region, country, or what the number can spell alpha-numerically when written down.

When a number is provisioned (also more commonly known as purchased), Twilio assigns that number to the customer. The phone number is now ready to be configured by the customer.

And that’s when the fun begins.

What can be done with a Twilio phone number?

There are many different ways that developers can use the numbers they get from us. But the two basic products that fuel the majority of uses cases on Twilio are voice and messaging communications.

Imagine a simple application to illustrate our examples here: a basic weather app that allows customers to request the current weather, as well as get an automated message every morning with what to expect for the day.

Receiving messages: What’s the weather?

In this first example, we want people to text our weather application with their location so that we can return to them their weather forecast.

We call this a carrier-initiated event. That message travels from a person’s phone to the carrier. At the carrier, a lookup will happen (much like how websites are looked up on the internet) to see who owns the recipient phone number. In this case, the carrier will see Twilio owns the number. That message will then get routed to Twilio via a protocol called SMPP, the protocol for text messaging.

Twilio receives the message from the carrier over a dedicated connection between Twilio and that carrier. The message then lands in Twilio’s messaging processing Stack where Twilio has written software to receive and interpret that message.

At this point, Twilio can recognize the phone number that should receive the message and will look up if the phone number has been configured with a messaging URL. The URL will point to the application endpoint that will handle inbound messages.

Twilio will then make a request to the application. This is called a Webhook.

The webhook is an HTTP request with the details of the message that was sent to the customer’s phone number. With the information in the request, the customer’s application can make a decision about how it wants to handle the SMS and, if so desired, provide a response to Twilio on how to proceed.

Responding with TwiML: “It’s warm outside!”

The application will respond in a language that Twilio designed named TwiML, short for Twilio Markup Language. This response contains a set of instructions that tells Twilio how to respond to the incoming message.

In this example, the application is returning the current weather. The response from the application will look something like:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Response>
    <Message>It is really freakin' sunny out!</Message>
</Response>

Developers will recognize that this looks a lot like HTML. Both HTML and TwiML are an extension of XML, eXtensible Markup Language. TwiML was specifically designed to be familiar to those who have worked with HTML or XML.

This Response is sent back to Twilio via HTTP where Twilio will transform it into an SMS response. Once translated, Twilio will send it back to the carrier via SMPP. The carrier is then responsible for returning that message to the user.

TwiML is designed to be as friendly as possible. Twilio supports context specific shortcuts for streamlining the response flow. In this case, there’s nothing in the response that tells Twilio who to send the message to. When processed in the messaging flow, Twilio will automatically send responses like this to the number that sent the original message.

So here we see the Twilio magic. Twilio turns real-world events into virtual signals that software can handle, and TwiML is the core technology Twilio provides that allows developers to easily respond to those real-world events. Developers get to use the same languages and protocols they’re already using in their web applications.
Sending messages: “You need your umbrella today!”

While it’s nice that we can request the current weather, it doesn’t make much sense to make everyone request it every day.

In this case, we want what is called an application-initiated event. These events start with a customer application and end up at the carriers where messages are delivered to their destination.

These events are initiated via Twilio’s public REST API, or application programming interface.

The REST API takes incoming HTTP requests and tries to perform the requested action. Twilio customers can make phone calls, send text messages, buy phone numbers, and otherwise interact with all of Twilio’s products and services.

The weather application can send an HTTP request to Twilio’s API to send a text message from the application’s phone number to a customer phone number, with a message containing the weather forecast. And Twilio will send back a response confirming receipt of the request.

But Twilio has not yet sent that message.

The API can send back a number of responses. If something went wrong in the application the API may not know how to interpret the request. Likewise, Twilio will respond if something goes wrong during the processing of the request. However, assuming that everything is working, and the customer account is in good standing, Twilio will send back a response confirming that it will honor the request.

Not all at once now

Inside Twilio, that message is added to a queue where messages are sent sequentially: first in, first out or FIFO. At the time this article was published, that rate was a constant 1 message per second. Changes coming in early 2020 will enable higher throughput based on sender reputation.

If an application needs a higher concurrent sending rate, or to send a large volume of messages, Twilio will offer additional solutions. For higher throughput messaging, today, an application can use a toll-free number. If very high throughput and bulk, synchronous deliverability is required the application should get set up on a special number, called a short code, that’s designed for large scale messaging.

After Twilio queues the message for delivery, the message is picked up by the service responsible for sending outbound messages. There, it’s passed on to the carrier via SMPP, and the day’s weather forecast is delivered to the destination phone.

And that’s an Application Initiated Event via the REST API, the opposite of a Carrier Initiated Event. Twilio takes a virtual signal and translates it into a real-world event, and your phone lights up with a voice call or text message.

Conclusion

Twilio provides a simple entry point into the telephony world, and helps your business avoid many of the traditional complexities. Developers can quickly get worldwide connectivity by interacting with Twilio using common internet protocols and simple markup.

This bridge between the internet and the telephone network is just the basic Foundation of Twilio’s product offerings – but it illustrates the power of what Twilio can do.

Developers can build software on the internet using technology they already know. Interacting with Twilio’s platform is much simpler than interacting with the expensive, complex, and costly world of telecommunications.

Now that you know what we do, sign up and give us a try.

Shawn Parker is the technical lead for Twilio’s growth engineering team. He can be reached at shawn [at] twilio.com.

Official twilio.com


src quora.com/What-is-twilio