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, ultimately enhancing 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 a few acronyms, where their practical meaning seems to mean different things to different people; and “SDK” is certainly one of them. If you’ve been in the industry long enough, it’s a term you’ve likely come across more times than you can count. “SDK” stands for “Software Development Kit” – and, as usual, such a broad and vague definition opens a lot of room for interpretation.

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

To draw 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, offering 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 much smaller projects (e.g. just a library + basic documentation for doing a very specific task) are also referred to as “SDK”, for instance Scandit – Barcode Scanning SDK. 

What does the WebTrit SDK contain?

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

The main component of WebTrit is a scalable cloud Backend, maintained by WebTrit team, which 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 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 (to save phone’s battery so an app wakes up only when there is an incoming call), contact sync (so user can see who from their phone book have also registered for the calling service), app auto-configuration, and other features. 

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

1. An easy to use API for call control, so a front-end or mobile developer doesn’t have to learn any peculiarities of VoIP protocols (and believe me, experience shows they 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 his/her balance of extension number. The API between the app and WebTrit backend is unified (so the app does not have to refactored should you decide to change your VoIP system from, say, Broadworks to PortaSwitch) and connect to any 3rd 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 (end-points).
3. A fully functional, production ready application, so they can white -label it, or adjust or build on top of it to create a product which delivers the required functionality – for instance: a video chat dating app, or “disposable phone numbers” app that allows people to safely sell things on Craigslist.

What are the unique advantages of WebTrit SDK?

The 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. 

The best analogy to describe the problems associated with this approach, is doing a construction project and going to a Home Depot store, which provides a wide variety of materials and tools. Yes, they have everything you potentially need – and one can find some instructions on how to use them. However, in order to successfully accomplish a simple project (a treehouse for your kids) or something of moderate complexity such as a garden shed (not speaking about something more complex such as a woodland cabin or a real house!) requires significant experience from the person doing the construction.

An ordinary person (not a professional builder with many years of experience doing something very similar!) trying to use such “raw” SDK most likely will be overwhelmed by the number of design choices and decisions that had to be made; the project will take a long time and has a high chance of failure – or at least major delays and exceeding the budget because of the need to redo things done incorrectly. 

As opposed to that WebTrit provides a fully functional and ready to be used application – not examples, not a “demo”, but the source code for the app, used by dozens telco and thousands of users around the world. So instead of getting a bunch of sacks of cement, wooden planks, pipes, wires, nails, etc. you waive your magic wand, say “flutter build” and you receive a fully assembled treehouse, garden shed, or cabin. But because it’s software, you can adjust or re-design with minimum effort – and focus only on the new things you need (e.g. a swing under the tree-house).

Now let’s examine the components more closely… 

Three components of 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 (smartphone app, “Call Me” widget on a web site, 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 front-end developer – so it operates with concepts such as “phone line” or “call”; one does 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.

At this moment the WebTrit team is working on creating “ready-to-use” libraries for popular front-end 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 (his/her monetary balance, configured email address, list of other extensions configured in the cloud PBX, etc.). 

1. 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. WebTrit backend sends a request to /session end-point of BSS adapter
3. 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, BSS Adapter creates a new authorized session and replies back with access_token, related to this session
5. 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 will turn off his/her smartphone). Then 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. 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. WebTrit backend initiates a SIP REGISTER request to the external PBX system
8. App requests a detailed information about the current user by sending a POST request to /user end-point in WebTrit backend API (supplying access_token in the HTTP Authorization: header)
9. WebTrit backend sends a request to /user end-point of BSS adapter
10. Adapter connects to PBX via its proprietary API, retrieves the data of this user and returns it back to WebTrit backend
11. WebTrit backend replies to the request from the app, providing a complete structure 
12. App displays user’s name, email, current balance, etc.

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

However 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), 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 back-end – and on another side it connects to the VoIP system or user database through its own protocol. There’s a separate post in WebTrit blog which describes in more details the architecture of BSS adapter

If you decide to write your own adapter, it is a good idea not to start from scratch but to use the BSS adapter project available on WebTrit GitHub page (BSS stands for Business Support System – basically any type of database that serves as the source of info about your users). It is a fully functional application written in 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 the walk-through the code of the BSS adapter, so you can write your own modules easier.

Ready-to-use application

Well, actually there are two applications:

#1 – Flutter app 

Written in Flutter/Dart, itcan be compiled into a smartphone app for Android / iOS – as well as intonative app for Windows/Linux/MacOS and a even web application. 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 tool-set 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 – the one that is used in production by multiple telecom operators and CSP (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 apps versions – or add extra functionality.   

WebTrit iOS app example

#2 – Web dialer 

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

Read the Success Story:

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

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

Here are a couple of key reasons:

• 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. WebTrit SDK accommodates these situations seamlessly, ensuring compatibility and flexibility in your development toolkit.

Embracing Open Collaboration

Conclusion: Unlock your WebRTC success