Talkpad inside

Almost a year has passed since the publication of the first introductory article on TalkPad . In the process of operation and development of the service, we encountered many technological problems, some of which were successfully overcome. Today we want to tell you how the TalkPad server side is arranged.

Let me remind you that TalkPad is a service that provides the ability to call landline and mobile phones directly from the browser by installing the plugin.

So, how can a backend for a highly loaded telephony service be arranged?

TalkPad is built on several data transfer protocols. We use SIP (Session Initiation Protocol) and SDP (Session Description Protocol) to establish a session between users and transfer metadata, and RTP (Real-Time Transport Protocol) is used to transfer voice data directly. There are other protocols for the connectivity task (Jingle, H.323, ...), but SIP is currently the most popular.

1. Locating users
In the project, we use the high-performance OpenSIPS software SIP switch , which, among other things, discusses the registration database.

In order for the server to know exactly where to send incoming calls, each client sends the server a SIP REGISTER message, in which it reports its network address and port. In order for the user to not be able to accept other people's calls, authentication and authorization are required in the SIP registration.

The registration database is maintained in the memory of each OpenSIPS server with periodic resetting (by timer) of the state to the local PostgreSQL (about how the data in memory is synchronized a bit lower).

2. And if the user is behind a NAT router?
Almost all users are behind home / office / public routers (NAT routers). In this case, the client does not know its external network address. To solve this problem, there is a protocol STUN (Session Traversal Utilities for NAT). A user's STUN client simply sends a request to a STUN server (one of the OpenSIPS modules), and the server responds with information from which network address the packet arrived. By combining various STUN tests, the user can determine his type of NAT.

The type of NAT that we defined is recorded in the SIP messages REGISTER and INVITE. In general, voice traffic is between clients directly in P2P mode. However, if the NAT type of one of the users has been defined as symmetric, we cannot do this. To do this, OpenSIPS rewrites SIP messages so that traffic between users is routed through an RTPProxy server (OpenSIPS module). According to TalkPad statistics, voice traffic through the server passes for approximately 28-30% of users.

3. SBC & Billing
In order for TalkPad users to be able to communicate not only among themselves, but also to call landline and cell phones, we cooperate with local telephony operators, who communicate with them using SIP and RTP protocols.

In order to correctly calculate the user's money expenditure, it’s not enough just to proxy the user's SIP messages to the operator, since in this case we will lose control over the call. A more suitable solution is to establish a new SIP session with the operator, but in such a way that RTP traffic is still routed directly between the user and the operator (or through the server if voice transcoding is necessary).

These functions are performed by the Session Border Controller (or B2BUA). In recent versions of OpenSIPS, the B2BUA module is already integrated. Alternatively, you can use B2BUA from Sippy Software . However, for TalkPad we settled on using YATE - the classic ATC company Null Team, which naturally combines PBX and SBC functionality.

One of the benefits of YATE is the Extmodule module, which makes it easy to write your extensions in Python. Twisted is used as an engine for processing asynchronous events . This is how we wrote a billing for TalkPad, which allows you to control the user's balance with second accuracy, even in the case of several simultaneous calls. This compares favorably with our billing solutions based on the RADIUS protocol.

4. Failover
TalkPad combines DNS balancing with CARP fault tolerance as shown in the picture.
OpenSIPS can proxy both in stateless proxy mode and statefull proxy mode, depending on the modules used. In our case, it is statefull and therefore we need the SIP client (voip plugin) to communicate with the same OpenSIPS throughout the session. Thus, the SIP client must resolve the DNS record 1 time at startup and use it until the end of the session.



Each OpenSIPS server replicates REGISTER to a neighboring server, adding itself to the Path header. This is necessary so that another OpenSIPS knows from which address the client needs to respond if necessary.

What happens if OpenSIPS-Server # 1 crashes?
In this case, the CARP1 interface on Server # 2 will automatically switch to the Master position, and both IP addresses of the DNS record will already be routed to Server # 2. This is most clearly shown in the picture:



If one of the YATE servers crashes, the loadbalancer module in OpenSIPS recognizes this situation and will use only the second server, and the fallen one will be periodically checked to see if it has come to life.

The scheme when just two users snapped up two different IPs and speak through the browser:



5. Databases
In the project, we use PostgreSQL and applications from the Skytools open-source suite (from Skype): pgbouncer connection puller and walmanager replication manager.

In this article, we briefly mentioned the main operating points of TalkPad. Next time we will talk about the features of cross-platform development of VoIP plug-ins for browsers.

Taking this opportunity, we want to inform you that the TalkPad team is actively looking for talented sellers, partners who would like to integrate telephony into their service, and investors.