Step 18. Function BLF (Busy Lamp Field)

To do this, the administrator configures the BLF function on Catherine’s SIP phone beforehand. To do this, when configuring the first button with the indicator, he enters Alice’s number and the second button with the indicator enters Boris’s number.

The BLF function works through SUBSCRIBE and NOTIFY SIP requests with special content, implementing the well-known Publisher-Subscriber pattern. The device subscribes to events, resulting in the system notifying the device whenever events of interest occur. For the BLF function, the events are the change of state of a particular user, more precisely the account of his SIP device (sipuser).

During this step, the user will be understood to be the account of his or her SIP device sipuser.

The state depends on the presence and status of calls, where the account is one of the callers. There are 4 states in total: terminated, idle, early, busy.

Given the above limitations, it is clear that notification of a user’s release cannot be produced directly by the B2BUA role, since it does not own the contexts of the user’s full set of calls on all instances of B2BUA roles at all sites. To reliably make a change decision, we need to integrate state from at least the set of individual states of all calls in which the user is involved.

The StateStore role is used to address this and similar issues. It collects and stores all the individual states that various system services, including instances of the B2BUA role, can associate with the user. It contains a "state machine" for computing integrated state. As well as a subscription and notification mechanism. It is redundant in Active-Passive mode, can be partitioned into groups by domain zones (microservice domain facades, step 7), synchronizes data between sites serving the domain.

Thus, a SUBSCRIBE subscription request, when processed on one of the B2BUA, temporarily places information about the subscriber in the subscription store of the StateStore role in the sipuser-addresser domain. The B2BUA instances, in the course of call servicing, define certain states (early, busy) for the user-subscribers - temporarily places the user-subscriber’s state information in the StateStore role’s state store in the corresponding domain and regularly renews. The StateStore recalculates the integral state of the associated _sipuser whenever it processes_ a request and notifies all subscribers when it changes. For this purpose, a corresponding request is sent to the serving B2BUA instance of each subscriber, the Command is transformed into a NOTIFY request and goes to the subscriber device.

It doesn’t matter

Any call involving user A will result in a synchronized change in A’s state across all sites serving his domain. Any change in user A’s state will result in notification to the user’s device C.

However, cross-domain subscription is only possible if C can invoke A according to the routing rules of both domains.