Devices without registration

The case was solved within the framework of the task #140.

Phones are connected to specific gates (role sg) to specific addresses (domains). This is the configuration of the phones.

The call from the phone goes through without authorization check (solely by sender address and connection to sipuser account without registration). The SG and B2BUA roles provide this part of the task, using unregistered account caches, keeping the data in them up to date. When calling from an unregistered account, the system behavior differs only in the authorization component, and username and domain are analyzed and used similarly to the standard mode.

When calling to the phone (to an account without registration), the system acts completely similarly to accounts with registration. The difference is hidden in the behavior of the independent back-end services that emulate registration. Thus, data about such accounts resides in the registrar (role sr) and is kept up to date there.

reg (of intbool type) defines the mode of account operation: with or without registration, by default true - with registration.

devices specifies a set of devices and their properties in object list format (array<object>):

Each account can contain multiple devs, and they are invoked by simultaneous forks.

Each device is bound to a specific gate so that the outgoing call to the account goes strictly through it. This ensures synchronization of devices, because the opposing device is similarly configured to a specific address. The value of the gates field can contain also * list of SrvIdx numbers, strings with ip address of the gate, strings with ip address and port, * value "" - a random gate on a site serving the domain and having a lexicographically minimal name is used. * empty list or empty string - the default value set in the domain settings (settings.ext.default_sipuser_noreg_gates) is used, it is expected that there is a number of RoleId, or ip address of a gate, or ip address and port of a gate, or a list of these values. If no value is specified, the behavior is similar . If the final value has no intersection with the gates of the sites serving the domain, then the account is not registered and calls to it are impossible, although from it calls will pass to the system through any gate on the sites serving the domain.

One particular device (the essence of the device address) can use multiple gates (role SG). In this case, the request for one device always goes only from one gate, the others are ignored and applied only when the gate is unavailable. Requests from devices, on the other hand, are accepted at any gates of sites that serve the domain to which the account belongs.

The number of device addresses must not exceed the number of licenses allocated to a given sipuser. Check and disallow change in each direction at the moment of account change.

If a gate address is specified that is not detected, the system does not enable it. And when you remove a gait from the configuration, it turns it off from operation without automatically deleting it from the account properties.

A special registration emulation service (role mware, Active-Passive on each site) supports the data in the registrar. It monitors the domain center (picking up accounts periodically) and reconciles with the past copy, creating/updating/deleting accounts in the registry while checking for available gates and ensuring that the path through an available gate is maintained in the registry.

The registration emulation service only deals with those devs (a subset of all account devs) that belong to the gates of the current site. This ensures that there is no duplication and no parasitic influences on the registrar from multiple sites, but at the same time requires that multiple gates belonging to different sites are not specified in the same device. This is the responsibility of the domain administrator.

To solve the problem of the case where the INVITE request has only an IP address in the domain field, a shared cache is used on the b2b. The sender’s address and port is used to determine if there is an unregistered device with the appropriate values in any domain served on the current site. If there are no such devices, the system operates in the normal mode, applying the algorithms of authorization and account detection by From and Authorization. If devices are detected, then depending on the number of accounts bound to that sender address, the number of domains at the address, and the From - domain or IPV4 - denies or processes the call, treating it as a call from a specific account of a specific domain.