Step 12: Call from one domain to another

The route search is performed on DC by a query from B2BUA. The number plan is configured using a set of routing rules - entities like route and vectorrule. The number is bound to the sipuser account through its phonenumber attribute with the requirement of uniqueness in the domain. First, among the routes (route) by mask (number From, number To, direction), the highest priority and matching schedule is searched for. Then, among the rules (vectorrule) related to the found route, the most prioritized and suitable according to the schedule is searched by masks (From number, To number, and direction). The action of the found rule is taken as the basis. The action can be a call barring, an internal direction, a transfer of responsibility to another domain with modifiers From and To, and a number of other directions.

Before transferring responsibility to another domain, B2BUA performs modification of the From and To numbers. They are then used to search for a route in the new domain resulting from the previous iteration of the search.

The configuration of routing rules in different domains is independent and is done by the administrators of those domains during CRUD operations on the route and vectorrule entities. In order for a call from Domain_A to Domain_B to occur, administrators in both domains create docking route routing rules. In Domain_A, a routing rule is created to go to Domain_B, and in Domain_B, a rule is created to accept such a transfer from Domain_A. Routing rules can vary significantly from domain to domain. But if a single a single end-to-end number plan for all domains, the routing rules can be grouped and their number drastically reduced. An example of such an end-to-end number plan is the classic 10-digit telephone numbering with area, city and subscriber codes. To avoid setting up rules in each domain to go to all other domains, a multi-stage transfer of responsibility between domains is used. For example, routing from each domain only to immediate children and to the parent domain with appropriate number conversion. Or create a special domain to provide full routing and assign an administrator responsible for numbering there.

The call taker sees the name of the caller as it is set in the name field of the sipuser account. The call initiator sees the name of the caller only after the caller hangs up. Constants and substitution fields can be used as values of the name field. For example, if the name is "Sokolov_\{D}", the system will substitute the From:DisplayName value from the INVITE SIP request received from the subscriber's SIP device instead of {D}. In this way, you can customize the display of "Sokolov_Work" and "Sokolov_Home"".

The initiator’s phone number to display to the caller is calculated using representative rules (representative entity). This may be necessary due to complex cross-domain number conversion rules. For example, to get to another domain, a rule is configured for numbers of the form subscriber_function_code+domain_number+subscriber_number_in_domain. Thus, within a domain it is sufficient to dial only the subscriber_number, but from other domains this may be not enough due to the routing rules. In order for an arbitrary call to leave in the phone’s memory the correct number of the caller from another domain and the possibility to call him back with the REDIAL button, the administrator can create a presentation rule, and B2BUA will apply it when creating a SIP dialog of party B.

Representations can be configured flexibly and individually with masks on the numbers and domains of the initiator and recipient.

However, unlike routing rules, the system does not support long chains of transferring responsibility between domains for constructing a representation. This is always the responsibility of the destination domain, which can be replaced by the responsibility of the sender domain in order to reduce the number of presentation rules when configuring a single number plan.