Users per PBX

The system works as a softswitch in the center, and on the periphery there are subdivisions. The units are connected to the system via ats-ki. PBXs are registered to the system as a provider. The task is to call the PBX not as a telephone, but by forwarding the dialed number.

That is, for example, the system has accounts dep1 (number 77777), dep2 (number 8888). Calls 11 from under dep1. dials 888815, it is necessary to route this call to the account of dep2 by giving him the number 15 in the request-uri. The From number must be 777711 so that a callback is possible. And DisplayName has to walk through, since it’s not a user.

The case was solved as part of tasks #86, #189 in 2017.

Any other subscriber can also call the atska, in which case its return number is calculated in the standard way. And the PBX itself can call any other existing subscriber in the system. That is, not necessarily from the PBX to another PBX. This separates the implementation of routing (selecting the account and destination number), and presentation (building from the INVITE request being sent).

Type action = internalpbx is entered for vectorrule. After modifying the rule with b2b, the account is searched by featurecode - by maximum prefix match (used by longmatch). The remainder of the number is considered an internal number. B2BUA actually organizes a normal internal call using spoofing rules, there requesturi is already fixed in the course of searching and processing routing rules.

Substitution of From when calling from the PBX. In this case action=internalpbx for vectorrule is not used. The difference between username in the From header of an incoming INVITE request and the real account registered in the system is considered to be a sign of a call from the internal PBX.

It is implemented in the r_sip_representative module. However, b2bua_router_utils use an alternative entry point to the representative by passing the Request. This is to find the real account sipuser. The standard interface method does not give information about other fields of the query, so a special method is made for B2BUA. It compares username from the AUTH header with number(username) from the header FROM.

If the AUTH header is not detected, it means that everything is fine in FROM, the system skipped the request considering it authorized, and therefore FROM.username matches the AUTH.username. The submission is acting as normal.

If AUTH.username = FROM.username, the view acts as normal.

If AUTH.username is different from FROM.username, then the real account, on behalf of which the call is made, is searched based on AUTH.username (instead of FROM.username), its number is calculated and goes in any case to search for a representation, even if the call is from the same domain. The from-number = SipUserNum + FromNum is sent to the domain center in the view search. That is, in the example above – 888811. Submission rules can modify this number at will. And if not detected or modified, it is substituted in this form in FROM of the sent invite.

The displayname value in this case (if From.username does not detect accounts) is thrown through.

When serving a call from a device registered under the sipuser account, the value of its name field is substituted as displayname in the From field of the request being sent to the recipient. The name field supports specifying modifiers.

For example, a value could be specified as: "Peter -{D} -{N}", so the above values from the context of the current call will be substituted for the modifiers.

The displayname field modifiers are used when throwing an INVITE request to the second arm, when throwing a response to the initiator, and when serving the re-INVITE.

The downstream PBX (B) is connected as described above to an account with the number 1234567, and it should be called as 1234567X, i.e. by adding the dialed number to the account number. However, the PBX itself sends calls from the 1234567X.

When the above number and extension splicing model is applied in its purest form, the PBX will be called by X number, and from it incoming calls will be analyzed by the system with number 12345671234567X.

A concept has been implemented where the principle of "Account number" + "extension number" is retained, but the extension is modified. Fields are inserted into sipuser

By default, modextin contains an empty string, so past the modifier goes unused extension. And modextout contains "*" by default, that is, the call goes to the calculated extension by the remainder after the long hunting.

If modextin specifies something, it applies to the field that is different from the account (can be From username or Contact username, including an empty value), or to From username if they both match. The modifier allows X/X, *, {U} - sipuser login, {N} - sipuser number, {F} - from username, {C} - contact username, regex sequences.

Total for modextin (incoming calls from account to system):

Sequences of regularizations to modify the predominantly distinguished value are also available. Even if this value is empty (in particular, in the Contact username header it is empty), a series of regex replacements can handle this situation. And if it is not empty and matches the account number, it can be easily described by a regular expression. The first handles the void, the second handles the number.

Total for modextout (outgoing from account):

In this case, each URI after resolution in the number plan and registrar will have its own modifier applied to it according to the sipuser account it corresponds to.