SIP Registration, Brunch, Softphone and Other Scary Words of Cloud Exchange Systems

Internet technology is a very big thing. Sometimes it happens that one develop different software, for different OS, using different programming languages for fifteen years and it seems to him that he knows a lot. Then a step to the side – and there Narnia  – SIP, RTP, SDP and PBX. The last few months, we are pretty busy with voice telephony, and several times I caught myself thinking that the documented area for beginners is not that very good. Well, if for some reason ten articles “IP telephony from scratch” is not written yet, then this is a good opportunity to write a post for a wide range of readers. Long posts I do not really like, so I’ll tell you a small, but the interesting part of the theory: how the cloud telephony systems interact with each other and with telecommunication companies.

A few words about SIP protocol

Most of the interaction occurs through a bunch of protocols and standards conventionally called “SIP-telephony” (sip trunking vs VoIP). SIP is one of the protocols from which everything usually begins. It is very similar to HTTP – the same plain text, headers, request bodies, answers. But instead of requesting web pages, the SIP protocol controls voice and video calls. The protocol itself, despite the 200-page RFC, is very laconic: it allows participants to register “phones”, initiate a call and answer it, end a call, plus a few service functions. Everything else is done through other protocols. For example, call parameters are transmitted in the body of SIP messages, but they are encoded using the SDP protocol. Moreover, the call itself is carried out via RTP or encrypted via SRTP protocols.

SIP Trunk

The simplest version of the interaction, widely used by telecommunication companies, is the “trunk”. In general, “SIP trunking” is the connection of subscribers not over a telephone cable, but via the Internet using the SIP protocol. However, for the communication between the telecom-telecom or telecom-cloud, this term has been accustomed. The trunk is made from two sides. At the beginning, from the cloud side, the IP addresses of the telecom are added to the white list: this will allow the telecom to make SIP calls to the chosen provider cloud without authorization. After that, the client contacts the telecom and informs him that he “lands” incoming calls to provider’s cloud. This uses the SIP URL, which corresponds to the account and the user’s application, which will use JavaScript (or another programming language) to inform the cloud what to do with these calls.

An important point is that this trunk is essentially “one-way”: our cloud will receive incoming calls from registered numbers, but it does not have the ability to “call” from such a number. That is, in fact, there are, but I will write about the substitution of numbers and traffic of traffic separately – and so already the wall of text turned out.

SIP Registration

If the trunk is a connection from the telecom to the cloud, then the SIP registration works in the opposite direction. The SIP stream has a REGISTER message (hence the name), which informs the server that a certain subscriber device is ready to receive calls. In order for the cloud to act as a subscriber device, the client needs to obtain the SIP addresses, logins and passwords from their numbers from the telecom and add this information to provider’s system in the admin panel.

Unlike the trunk, SIP-registration works in both directions: having logins and passwords, the cloud accepts and makes calls to the specified numbers. Another difference is that SIP registration is part of the SIP protocol (a regularly sent REGISTER message), while trunks are just the practice of using SIP solutions.