Step 11. First call

Devices are registered. We’ll make the call.

According to the scheme known from step 10 the SIP request INVITE gets to SG and is proxied to the B2BUA.

The peculiarity of the INVITE request transaction is that it is endowed with states and controlled, in particular, it can be sent preliminary responses, it can be canceled by CANCEL request. The result of a successfully processed INVITE request is the creation of a SIP dialog between two UAs. Repeat: When processing SIP INVITE requests to make calls, B2BUA acts as an oppositional UA for the request initiator. It arranges authorization verification, routing, answering party lookup, and arranges the second arm of the dialog, including multiple calling. For both subscribers (caller and called) it is a full-fledged UA, thus combining two SIP dialogs within a single call. The concepts of SIP-dialog and B2B-dialog are distinguished.

Corollary 1: In a call from one user to another between two SIP devices, there are always exactly 3 SIP nodes in the chain - SG, B2B, SG. If they are registered through one SG instance, it is the same SG serving two shoulders, i.e. two SIP dialogs.

Corollary 2: The SG of the call initiator and B2BUA are always located at the same site, while the SG of the call recipient can be at any site.

Corollary 3: B2BUA only creates B2B dialogs when initiated externally, so in any B2B dialog there is an initiator and there is a recipient of the call. However, there is one exception here - the intercept function - two initiators are connected in the same dialog. Subscriber A is the one who initiated the original call, and Subscriber B is the one who called the code for the subscriber intercept function.

Audio and video data associated with the call are transmitted using the RTP protocol. As part of the connection establishment transaction, parties A and B exchange media stream descriptors using the SDP protocol (wrapped in the body of the INVITE request and 200 OK response). The transmission of media traffic is handled by the media server as part of the MG role. The performance of this function is very critical, and it is implemented in a separate RTX application included in the platform. In essence, the MG role is a wrapper over the media server RTX.

MG (by means of an RTX media server) performs traffic exchange, audio mixing in conferences, transcoding - repackaging traffic from one codec to another (audio or video). One average server can handle 200-500 simultaneous calls. The exact number depends on a large number of factors: processor performance, server participation in other tasks besides media-server, presence of transcoding in calls, presence of video traffic and video transcoding in calls. Thus the expansion in the site of the number of servers dedicated to media servers grows along with the increasing requirements for the number of calls served simultaneously. They are redundant and scalable in mode Active-Active.

RTX is controlled by the MEGACO protocol. The opposing party implementing the MEGACO protocol is the MGC role. Its main responsibilities are to select the most free suitable media server from its group and to broadcast the management of Media Contexts calls: creating a Media Context, adding Media Terminals to it, setting Media Topology, Terminals properties, starting playback and recording. Multiple Groups of MGC can be configured on a site, each of which is reserved in Active-Passive mode and manages multiple MG.

The creation of the media context for the call is initiated by the B2BUA, which selects an _ MGC group_ immediately after the B2B dialog is created. If the selected group fails, the B2BUA tries another group. Further, each new SIP message at the signaling control layer of one party’s SIP dialog results in adjustments to the media context: media terms are added, deleted, or modified.

Corollary 4: The call traffic is exchanged by the media server of the site where the instance serving the call is located B2BUA.

Corollary 5++: No matter how dispersed the sites are - traffic is always sent via the shortest route through the site to which the call initiator’s device is connected.

Corollary 6: In order for calls between two sites to take place, there must be direct network visibility between all B2BUA, SG, and MG instances of these sites.