Step 10. Attaching the SIP-phone

SIP-devices work with the SIP protocol (a large set of RFCs, starting from the most basic 3261). The device in the case under consideration generates only signaling traffic, SIP itself. Namely, it sends a REGISTER request and expects to receive a 200 OK response or a response with error code 4xx-6xx. Registration of the device is carried out for a specified time (usually within 1 hour), during which the device extends the registration by sending the next REGISTER request with the same identifier, or creates a registration with a new identifier. The domain name is the logical name of the domain in which the SIP-device account is created, and this name may not exist in DNS if proxy-addressing is used.

The diagram introduces new functional elements. It reflects the presence of SIP-Boundary, i.e. the necessity to have in one of the system roles on one of the servers the functionality responsible for receiving and standardized processing of SIP protocol transactions. Functional element SIP-Server processes the REGISTER request, authenticating it (its task is similar to the previously considered task of the role WS - there the HTTP protocol processed requests from the User-API, and here API standard for SIP protocol is processed, now it is REGISTER request). And Registrar_Storage - temporarily stores the registration. DC solves authorization issues in a way similar to user authorization when running the API in step 1, but another domain entity is used to authorize SIP devices - the SIP-UA (sipuser) account. It is the one that is pre-created by an administrator in one of the domains, and it is the one that contains the login and password entered by the entered by the user when configuring his SIP-phone.

The scheme is as simplified as possible, focusing on the need to distinguish three types of new functionality. At this stage it is necessary to clarify the essence of SIP-Boundary, SIP-Server and Registrar_Storage, or rather the necessity of their isolation, as well as to link them to specific roles of the system.

If we do not take into account the purpose and meaning of device registration, it is impossible to adequately assess the need for separation of functionality. Therefore, let us partially anticipate the following case:

In this form, it is sufficient for now. To make a call to user B, some process has to access the registrar storage. The dialed number in the DC reveals an account, and the account in the Registrar_Storage reveals the address of the registered SIP device to which the call should be routed.

We provide service availability and scalability. If these three functionalities were inseparable in just one place, then there would be no scaling potential. And if they were present indivisibly in multiple instances of the same role - some users would be logged on one server, some on another. Calls between them would be impossible, or, in the extreme case, it would be necessary to search all servers in the entire system for each call - a regression of the speed and performance. Thus, the necessity to allocate the storage of SIP-device registrations is justified. This is the Registrar role. Its main responsibility is safe storage of all registered SIP-devices. It is redundant in Active-Passive mode, divided into groups by domain zones (microservice domain facades, step 7), synchronizes data between sites serving the domain. It stores the data in an object database distributed among the role group servers.

The need to separate SIP-Boundary and SIP-Server will become transparent once other functional responsibilities are separated between them.

Both have SIP interfaces, are redundant and scalable in mode Active-Active.

This arrangement of functionality gives more architectural maneuverability. In particular, there can be different numbers of servers with the SG role and with the B2BUA role. We will explore the SG and B2BUA roles in more detail in step 11.

An important special case study of this step is that phone registration to a domain may be from a site where the domain is not served. In this case, the registration data will be stored on all sites where the domain is served and point to the device’s connection point, i.e. the SG of the other site. This happens through Registrar functionality, namely proxying and synchronization. This feature is called roaming.

Another special case is the ability to register multiple SIP devices under one account. This is limited only by the respective license and may be restricted differently for different users.