Making the switch to Bandwidth
Today’s average U.S. smartphone user spends a whopping 4.7 hours per day engaged with their device. That number may not surprise you, but it does reinforce the fact that now is a great time to be in the business of helping people communicate. Whether you’re developing an Over-The-Top (OTT) app, embedding Real-Time Communications into your software solution, enabling in-app texting for the first time or empowering your users with new voice notification functionality—you can access it all through the power of voice and messaging APIs.
But are all communications APIs created equal? We think not, but it’s important to evaluate your needs carefully and then select a provider that can help you accomplish your goals. Rest assured, when the time comes to make the switch to Bandwidth, we make the process quick and easy.
Evaluating Your Needs
Bandwidth is hardly the first player in the space of Communication APIs (CPaaS). However, Bandwidth IS the first player that brings its own network to the CPaaS game. We have had many customers switch to us for our combination of: top tier customer service, customization, and detailed, 6-second pricing. The most common reaction from customers was, “Wow! Making the switch to Bandwidth was easier than I thought it would be.”
To make for a transition, there are 3 important steps you’ll need to take with important considerations along the way.
- Learn the differences between the APIs
- Determine and scope what code needs to be changed
- Implement Changes
1) Learn the difference between the APIs
Estimated Scope – 5 Point Spike
Bandwidth and other CPaaS offerings have lots in common but some important differences.
Each provider has the basics covered. Make a phone call, receive a phone call. Send text message, receive text messages. And so on… How each of the providers allows its users to accomplish this task differs. Some of the key differences to focus on include:
- Incoming Calls
- Incoming Messages
- Number ordering
- Answer events
- Hangup events
Rest API & Callbacks vs BXML
Bandwidth provides two separate options to interact with phone calls and text messages. As part of the discovery phase, it’s important to learn the differences between the two.
Rest API & Callbacks – You control everything
Using the Rest API with callbacks allows for the most complete control over calls and messaging. For a single call flow, each step needs to be verbosely configured. Incoming calls need to be answered, each call leg must be manually put into a bridge, each call needs to be hung up. Essentially, zero state is managed by Bandwidth and must be maintained externally. This leads to EXTREME flexibility.
Examples: Calls can be added and removed to a bridge, allowing developers to add/remove callers on a single bridge. Conference calls have the ability to speak notes or play audio to individual callers. Call recording can be toggled on/off. Calls can be forwarded to simulring any number of phones.
BXML – Contain call flow (most similar to other CPaaS)
BXML relies on an XML document to control call flows and messaging. BXML simplifies complex scenarios like conference calling and simulring forwarding. Where Rest API requires call state to be managed externally, all state for BXML is handled within the xml document.
2) Determine and scope changes
Estimated Scope – 8 Point Spike
Once the main differences between the two APIs have been identified, it’s time to scope out any code changes. Some of the key focus points should be around:
- Callback events, such as:
- Incoming Call
- Answer
- Hangup
- Incoming Message
- Outbound call creation
- Outbound message creation
- Database changes
Most of the call logic remains the same, but it’s important to spend time investigating the code around the logic. Certain things like message and call creation require different parameters than other CPaaS providers. Further, it’s important to keep any database tables and calls up to date to reflect how Bandwidth tracks minute usage. It’s also important to ensure any endpoints are updated to accept Bandwidth callbacks. Depending on the choices above for BXML and Rest API, Bandwidth expects different responses from the called web server.
For this step, focus on identifying the pieces of code that interact with the old CPaaS and estimate the amount of work to transform them.
3) Implementing the change
Estimated Scope – 8-16 Point Story/Epic
Obviously, implementing the changes discovered in the Spike will take varying amounts of time based on the business logic. Some customers such as Rover.com were able to migrate in about a week with a single engineer. Other customers with more complicated call flows migrated in a month or so with a single engineer. Luckily, all CPaaS offerings require the same level fine-grained thinking. Each ‘call event’ has to be handled somewhere or another. Each incoming message will always be sent to a callback url. So to speak, the work is in the details. Be sure to narrow and focus on any ‘trickeries’ or ‘hacks’ used to achieve certain flows with previous providers. They’re most likely not the same with Bandwidth and may not even require a ‘hack’ to get working. Bandwidth also provides high level SDKs for most of the popular languages. There is a good chance, if you code in it, we have an SDK to support your migration.
Conclusion
Following the steps above will ensure that the migration goes smoothly in a timely manner. Key takeaways are to identify and learn the differences between Bandwidth’s API and your previous CPaaS, implement the changes, leverage SDKs, and ensure that any billing logic on duration is updated to key off Bandwidth events.
1Chang, Lulu, “Americans spend an alarming amount of time checking social media on their phones,” Digital Trends, 6/13/12015