Talkpad inside

Almost a year after the publication of the first introductory article on TalkPad . During the operation and development of the service, we faced many technological problems, some of which were successfully overcome. Today we want to tell you about how the server side TalkPad.

Let me remind you that TalkPad is a service that provides an opportunity to call landline and mobile phones directly from the browser, installing the plugin.
')
So, how can the backend of a high-load telephony service be arranged?

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

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

In order for the server to know exactly where to send incoming calls, each client sends a REGISTER SIP message to the server in which it reports its network address and port. Authentication and authorization is required to prevent the user from accepting other people's calls in SIP registration.

The registration database is maintained in the memory of each OpenSIPS server with a periodic dropping (by timer) of the state into the local PostgreSQL (how the data in the memory is synchronized just below).

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). The user's STUN client simply sends a request to the STUN server (one of the OpenSIPS modules), and the server responds with the information from which network address the packet came from. By combining various STUN tests, the user can determine his NAT type.

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

3. SBC & Billing
In order for TalkPad users to communicate not only with each other, but also make calls to landline and mobile phones, we cooperate with local telephone operators, which also communicate using SIP and RTP protocols.

To correctly calculate the user's cash flow, it is not enough just to proxy the user's SIP messages to the operator, since in this case we will lose control over the call progress. A more appropriate solution is to establish a new SIP session with the operator, but in such a way that the RTP traffic is still directed 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 the latest versions of OpenSIPS, the B2BUA module is already integrated. In addition, you can use B2BUA from Sippy Software . However, for TalkPad, we settled on using YATE , the classic ATC of the company Null Team, which naturally combines PBX and SBC functionality.

One of the advantages of YATE is the Extmodule module, which makes it easy to write your own extensions in Python. Twisted is used as the engine for handling asynchronous events. In this way, 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 distinguishes our billing from 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, this is a statefull and therefore we need the SIP client (voip plugin) to communicate with the same OpenSIPS during the session. Thus, the SIP client must remove the DNS record 1 time at startup and use it until the end of the session.



Each OpenSIPS server replicates the REGISTER to a neighboring server, appending itself to the Path header. This is necessary in order for another OpenSIPS to know from which address it is necessary to respond to the client, 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 records will already be routed to Server # 2. This is most clearly shown in the picture:



If one of the YATE servers fails, 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 cut off two different IP and speak through the browser:



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

In this article, we briefly mentioned the main points of operation of the 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 retailers, partners who would like to integrate telephony into their service, and investors.