WebTrit SDK: Elevating WebRTC developer satisfaction

The WebTrit SDK is a powerful tool designed to accelerate the development of WebRTC voice and video communication apps. The goal: to ultimately enhance the customer experience. 

In this article, we will explore the key distinctions between the WebTrit SDK and other WebRTC-related SDKs. Our aim is to demonstrate how WebTrit can expedite your time-to-market, reduce future feature costs, and bring joy to your WebRTC developers. 

What is an “SDK”?

In the dynamic realm of software development there are several acronyms that seems – at least in practice – to mean different things to different people. “SDK” is certainly one of them. If you’ve been in the industry for a while, you’ve likely come across this term more times than you can count. And you may know that it has an actual meaning: SDK stands for “Software Development Kit.” A bit broad and vague, right? So from there, however, a lot of room for interpretation typically opens up.

Think of SDK as a powerhouse toolkit. It’s a set of software tools, libraries, and sometimes even relevant documentation, all tailored to facilitate the creation of applications for a specific platform or framework. In other words: anything that helps the software developer create a new application more efficiently.

To see a clearer picture, consider the Android SDK. For developers aiming to design apps for the Android platform, this kit provides the essential tools, including libraries, a handset emulator, debuggers, and documentation. Another vivid example is Apple’s iOS SDK, which equips developers with the necessary tools to create apps for Apple’s operating system. It offers a range of functionalities, from interface design to intricate system calls. And let’s not forget game developers, who lean heavily on Unity’s SDK when crafting immersive gaming experiences. 

At the same time, plenty of smaller projects (e.g., just a library + basic documentation for doing a very specific task) are also referred to as “SDK”. A good example is the Scandit barcode scanning SDK. 

What is the WebTrit SDK?

So where does WebTrit fit into this SDK scale? WebTrit allows developers to create new WebRTC voice/video communication apps for smartphones, websites, or native applications for Linux/Windows/MacOS. And it allows them to do it much faster. 

The main component of WebTrit is a scalable cloud backend, maintained by WebTrit team. It converts WebRTC calls into standard VoIP sessions, which can connect to real telco networks. This means it enables users of the app to make calls (and more) to real phone numbers (mobile or landline) or receive incoming calls made to real phone numbers. All this without the need to have a devops and VoIP expert on the team to maintain that infrastructure. The WebTrit backend also provides auxiliary functions, such as push notifications. (These help save phone battery life by allowing the app to “sleep” and wake up only when there is an incoming call.) It also provides contact sync (so users can see who from their phone book have also registered for the calling service), app auto-configuration, and other features. 

What does the WebTrit SDK contain?

To allow programmers to use & control these functionalities, the WebTrit SDK includes:

1. An easy-to-use API for call control, so a frontend or mobile developer doesn’t have to learn any of the peculiarities of VoIP protocols. (Believe us, plenty of personal experience shows that developers truly hate learning about SIP messages, SDP, and so forth.)
2. An API for the app to retrieve user info, already configured in the existing VoIP system – for instance, their balance or extension number. The API between the app and the WebTrit backend is unified (so the app does not have to be refactored should you decide to change your VoIP system from, say, Broadworks to PortaSwitch) and connect to any third-party VoIP system or user data repository, as the connection to that external system is implemented as a micro-service. So a developer connects WebTrit to a third-party system (cloud PBX, VoIP switch, telco BSS, etc.) for user authorization, retrieval of SIP settings, retrieval of corporate directory / list of extensions, new user sign up, etc. by providing their own API adapter with only a dozen functions (endpoints).
3. A fully functional, production-ready application, so they can white-label it (in other words, any company can label it as their own brand), or adjust or build on top of it to create a product that delivers the required functionality… For instance: a video chat dating app, or a “disposable phone numbers” app that allows people to safely sell things on Craigslist.

What are the unique advantages of the WebTrit SDK?

That last item (jump-starting the development by getting access to the source code of a full application) is a crucial difference between WebTrit and other WebRTC SDKs available today. Most of them provide libraries, documentation, and some basic examples of using specific methods of functions. The developer is then responsible for all the application structure and implementing all required things. Even mundane ones, such as a “list of contacts” or application wake up on push notifications. 

Here’s an analogy to describe the problems associated with this approach. You’re doing a construction project and you go to a big-box home hardware store. The store, say a Home Depot, provides a huge variety of materials and tools. Yes, they have everything you potentially need – and there are folks there who can direct you on where to find instructions on how to use them. But having access to those things does not guarantee that you will be able to successfully build your project, whether it is simple (a sandbox for your kids) or moderately complex (a garden shed). Never mind if it is massively complete (a cabin). Guaranteed success requires significant experience from the person doing the construction.

It’s the same with SDKs. An ordinary person (not a professional developer with many years of experience of doing similar things) trying to use a “raw” SDK will most likely be overwhelmed by the number of design choices and decisions that have to be made. The project will take a long time and have a high chance of failure. Or, at least, major delays and an exceeded budget because of the need to redo a bunch of things. 

WebTrit, on the other hand, is not “raw.” It provides a fully functional and ready-to-use application. Not examples, not a “demo,” but the source code for the app, already used by dozens of telcos and thousands of users around the world. So, to go back to our analogy, instead of getting a bunch of sacks of cement, wooden planks, pipes, wires, nails, etc., you can wave your magic wand, say “flutter build” and receive a fully assembled treehouse, garden shed, or cabin. And because it’s software, you can adjust or re-design your project with minimal effort – and focus only on the new things you need (e.g. a swingset to go with your sandbox, or a greenhouse roof for your shed).

Now let’s examine the components of the WebTrit SDK more closely… 

Three components of the WebTrit SDK

Call Control API

WebTrit Signaling Protocol (WTSP) is based on web sockets (which allow efficient two-way exchange of events between the client and the server). The full documentation is available on WebTrit Github page. 

It allows the client (whether that’s a smartphone app, “Call Me” widget on a website, dialer widget inside of CRM or cloud call center agent workspace, etc.) to:

• Initiate call requests (establish a new call, place a call on hold, disconnect the call, etc.)
• Receive notifications about changes to the call state from the server (e.g. there is a new incoming call, so the agent should be notified; or the call has been disconnected by the other party – so the information on the screen has to be updated accordingly)

The main idea is that the API should be comprehensible for an ordinary frontend developer. So, it operates with concepts such as “phone line” or “call”; you do not have to study VoIP related documents or protocols. To give you an idea: the “main” RFC for SIP protocol (RFC-3261) has more than 250 pages; it is “extended” by over 20 other RFCs (some of which may be almost as big!). So compared to this, WTSP is extremely simple and a developer should be familiar with it in just a few hours.

As you read this, the WebTrit team is working on creating “ready-to-use” libraries for popular frontend languages (e.g. TypeScript) to make it even simpler to embed WebTrit / WebRTC calling into applications such as CRM, where one does not need a full-scale functionality.

User Data API / BSS Adapter API

This API is used to authenticate a user who is logging into the application and obtain further information (their monetary balance, configured email address, list of other extensions configured in the cloud PBX, etc.). 

1. The app performs “login” by sending a POST request to /session end-point in WebTrit backend API, providing username & password (entered by the user) as parameters.  
2. The WebTrit backend sends a request to /session end-point of BSS adapter.
3. The adapter connects to PBX via its proprietary API, searches for a user with such ID, verifies the password. 
4. Assuming everything went fine in the previous step, i.e. the user is authenticated, the BSS Adapter creates a new authorized session and replies back with access_token, related to this session.
5. The WebTrit backend stores that access_token (and refresh_token if provided) in its cloud database (so it can now perform actions such as periodic retrieval of user data and maintain SIP registration even if a user turns off their smartphone). Then the WebTrit backend generates a different access_token, which will be used to authenticate further requests from the app to the “user info” API (for example in order to obtain user information such as balance or SIP credentials) and authorize requests to WebTrit call control API. This way, nothing changes on the app side even if the API token, issued by the adapter, expires in the future and a new one has to be obtained via refresh_token.
6. The WebTrit backend returns this new “app facing” access_token to the app – from now on it will be used as a way to securely authenticate an app. 
7. The WebTrit backend initiates a SIP REGISTER request to the external PBX system.
8. The app requests detailed information about the current user by sending a POST request to /user endpoint in the WebTrit backend API (supplying access_token in the HTTP Authorization: header).
9. The WebTrit backend sends a request to /user end-point of the BSS adapter.
10. The adapter connects to the PBX system via its proprietary API, retrieves the data of this user and returns it back to the WebTrit backend.
11. The WebTrit backend replies to the request from the app, providing a complete structure. 
12. The app displays the user’s name, email, current balance, etc.

This is a “classic” HTTP REST API (here is the documentation about the available methods).

Things to consider

In order for this to work (e.g. an app sends a request to /app/contacts requesting a list of all extensions in the cloud PBX), the WebTrit backend has to connect to the actual VoIP systems via its proprietary API and extract that data from there. This is done by implementing a custom micro-service, which (on one side) implements the set of standard methods, used by WebTrit backend. And on another side, it connects to the VoIP system or user database through its own protocol. There’s a separate post in the WebTrit blog which describes in more detail the architecture of the BSS adapter

If you decide to write your own adapter, it’s a good idea not to start from scratch. Instead, use the BSS adapter project available on the WebTrit GitHub page. (By the way, BSS stands for Business Support System. It’s basically any type of database that serves as the source of info about your users.) It is a fully functional application written in the Python programming language, using FastAPI framework and ready to be packaged into a Docker container for further deployment in the cloud environment such as Kubernetes or Google Cloud Run. It includes:

• a web server to process inbound HTTP requests and proper API interface towards WebTrit 
• WebTrit’s API schema converted into Python classes for data validation and ensuring compatibility of the data structures with WebTrit backend
• Foundational classes for programming your own adapter, so your job is to extend those with a few fairly simple methods, which connect to the third-party system and do the required data mapping
• Sample modules for popular VoIP systems such as FreePBX or 3CX

There are a few videos on the WebTrit YouTube channel, with a walk-through of the code of the BSS adapter. That should help you so write your own modules easier.

Ready-to-use application

Well, actually there are two applications:

#1 – Flutter app 

Written in Flutter/Dart, it can be compiled into a smartphone app for Android / iOS. (Or an intonative app for Windows/Linux/MacOS and a even web application.) Here is the source code for WebTrit voice & video calling application in Flutter

Flutter is an open-source programming framework created by Google that allows developers to create different applications for different platforms within one single code-base.  It is a powerful toolset that allows you to create pixel-perfect mobile apps across iOS and Android, and is much more time-efficient than building native apps. 

Our WebTrit Flutter project is fully complete application. It is already being used in production by multiple telecom operators and CSPs (communication service providers) around the world. Just open it up in an IDE such as Android Studio or Visual Studio Code and you are ready to tweak it to create your own white-label WebTrit app versions. (Or add extra functionality.)   

WebTrit iOS app example

#2 – Web dialer 

This is a web-only (hosted on a website and accessed from a web browser such as Chrome or Safari) application written in Javascript/Vue. Access the source code of WebTrit web dialer or check the demo version here (just type your email address to login).

Read a WebTrit Success Story

How a communication service provider transformed their cloud call center with WebTrit’s web dialer.

Making the right choice: Why choose WebTrit SDK over Flutter App

Here are a couple of key reasons:

• A wider pool of developers: Unlike Flutter, which has a dedicated but relatively smaller developer community, the realm of ‘traditional’ web development with JavaScript and frameworks like Vue or Angular boasts a much larger talent pool. This abundance of skilled front-end developers makes it easier to customize and deploy services, especially if you only require a web version.
• Compatibility: In some scenarios, such as creating plugins for popular CRMs or building websites on platforms like WordPress, JavaScript becomes the sole available technology. The WebTrit SDK accommodates these situations seamlessly, ensuring compatibility and flexibility in your development toolkit.

Embracing open collaboration

Unlock your WebRTC success