Step 15: Call Holds and Transfers

During the hold time, the waiting subscriber hears the waiting tones played by the server.

Since each B2B dialog is represented by two SIP dialogs - arm A and arm B, it is important to ensure that the correct arm is substituted when spoofing. Without this, the Barbarian device will not be able to detect the spoofed dialog, and the spoofing will not occur - instead, the device will either refuse the call or make a second call reception. The problem exists insofar as Alice’s device knows only its shoulder A about the dialog with Catherine, and its identifiers differ from shoulder B, i.e., from what Catherine’s device knows about the same dialog. Alice’s device sends a REFER request with a swap, specifying the parameters of its shoulder A of the dialog with Catherine as the swap, while Catherine’s device requires the parameters of shoulder B of the same dialog for a successful swap.

The B2B role solves this problem on its own by direct communication between its instances (without regard to the sites on which they reside). Either at the moment of REFER+replaces request transfer, or at the moment of INVITE+Replaces processing, the B2B role instance makes a direct request to the adjacent B2B role instance, where the target dialog is served, and uses it to modify the shoulder identifiers.

The target B2B (in the B2B-2 instances) is discovered directly. Each instance of B2B conducting a call through itself to each of the shoulders places "talking" identifiers. A To-Tag is generated for shoulder A, and a From-Tag and Call-ID are generated for all shoulders B. Each of the generated values contains data from which the address of the B2B instance that made the generation can be identified using configuration. Thus, to replace the ID values of one arm with those of another arm, it is sufficient to have both From-Tag and To-Tag, use them to find out the serving B2B instance, and use it to make the replacement. This is how the function works. In the REFER query, the Replaces attribute contains the Call-ID, From-Tag, To-Tag. And in the INVITE request, the Replaces, Refer-To headers contain the same shoulder IDs, and possibly an attribute of the already performed replacement.

The SIP protocol and its extensions define the provision of such behavior of devices. The device from which the transfer is initiated performs the subscription, and the device performing this transfer notifies the subscriber about the state of the redirected call - broadcasts to it the responses received from the third party to the INVITE sent by it. This interaction takes place within the framework of the dialog whose transfer is being performed.

Thus, one device within this dialog sends a REFER request to the opponent, and the opponent sends NOTIFY requests in the opposite direction, translating all received responses. Only after receiving a NOTIFY with a translated response of 200 OK, the transfer initiator device terminates the dialog being translated. Accordingly, upon receiving a NOTIFY with a final failed response, the initiator device reconnects in the translated dialog. If it is a device (telephone), it is in passive mode the whole time after sending a REFER request. If the handset is lying on the phone, the phone starts calling its user and only then connects in the translated dialog.

The B2B role translates REFER and NOTIFY requests and their responses.

What happens to the media servers (roles MGC, MG, BGMG)? As parsed in step 11, each instance of the B2B role connects a MG media server to each dialog it serves via the MGC media controller. The MGC and MG are selected within the same site as the instance B2B.

The scheme shows that in any B2B dialog regardless of whether, * what types of subscribers are involved - internal users, external subscribers or internal services, * which domains the subscribers belong to, * what configuration of sites is set up, * how the dialog is created - by direct call, transfer to number or transfer with substitution, the dialog is serviced by a SIP server (B2B role) and a media server (MG role) located at one of the sites to which the participants of this dialog are connected.

Thus provided the media servers within a site are indistinguishable, traffic is always carried over the shortest possible route. SIP signaling is sent through 3 servers, RTP traffic is sent through 1 media server if networks are visible and through 2 or 3 if media traffic needs to be broadcast from one subnet to another at the edge (step 14). With sites in Lisbon, Paris and Rome, if a subscriber from Paris calls to Lisbon - served by Paris servers, a consultation call from Lisbon to Rome is served by Lisbon servers, a transferred call from Paris to Rome will be served by Paris servers. And in case of reverse transfer of a subscriber from Rome to a subscriber from Paris - their dialog will be serviced by Rome servers.