Multi-Site Call Scenarios

A basic principle for multi-site reporting is that T-Server does not try to support the same model for multi-site calls as it does for those that are local. Instead, it is the client's responsibility to merge call information into a single unit based on the call's relationship information provided by T-Server. To help with multi-site call reporting, Genesys has introduced the Inter-Site Link (IS-Link) with the following properties:

• Each IS-Link has a UUID, assigned at the time of creation and reported in ISLinkList.
• For Hot Standby redundant environments, IS-Links on each side are also replicated from the primary to the backup T-Server.
• At any moment, IS-Link may be associated with no more than two calls (located on different T-Servers).
• IS-Link may represent a communication channel, for instance, a voice channel between calls in different switching domains.
• Alternatively, IS-Link may associate two calls that continue each other, connected together through association with the same external participant, for instance, an incoming call overflowed or re-routed by an external network to another switching domain.
• On each T-Server the IS-Link–associated call is reported in the context of the CallUUID, independent of the other T-Server.
• The IS-Link call association does not depend on any T-Server options. In the Multi-Site Call Transfer diagram, for instance, the link is always connected to the call labelled cons, even if T-Server is instructed to populate the ConnID/UserData of the call labelled orig for the remote site.
• An IS-Link may be re-attached to a different call on the same T-Server, but only as a result of a merge operation. This action is not reported explicitly, but assumed from EventCallDeleted, with a RefCallUUID attribute specification.
• A call may have more than one associated IS-Link.
• In some scenarios when there is an overflow from a queue, an IS-Link may be attached to a call after the call is reported as deleted.

The following diagram illustrates a case of three related calls, of which only two are linked together.

Multi-Site Call Transfer

The association between an IS-Link and a call is reported in EventCallDataChanged, which is distributed to call-monitoring clients. Often, the same event may also report a change in ConnID and UserData as the result of multi-site synchronization.

Important

In most cases, IS-Link is attached before the first DN-based event is sent. (That is, before EventRinging and EventRouteRequest.) The exception is with events for trunks that have trunk monitoring. T-Server clients should be capable of processing later updates.

Simple Multi-Site Call

In this scenario, events for which are described in the following table, DN A on Site 1 calls DN B on Site 2.

Origination (Site 1)			Destination (Site 2)
DN-Based Events	Call-Based Notifications		DN-Based Events	Call-Based Notifications
A: TMakeCall to B (Site 2)
	EventCallCreated CallUUID UUID-X ConnID x
EventDialing CallUUID UUID-X ConnID c (x replaced by ISCC) ThisDN A OtherDN B a	EventCallDataChanged CallUUID UUID-X ConnID c ISLinkList UUID-L@'site2'
EventNetworkReached (Optional) CallUUID UUID-X ConnID c ThisDN A OtherDN B a				EventCallCreated CallUUID UUID-Y ConnID y
			EventRinging CallUUID UUID-Y ConnID c (y replaced by ISCC) ThisDN B OtherDN A a	EventCallData-Changed CallUUID UUID-Y ConnID c ISLinkList UUID-L@'site1'
			B: TAnswerCall()
EventEstablished CallUUID UUID-X ConnID c ThisDN A OtherDN B a			EventEstablished CallUUID UUID-Y ConnID c ThisDN B OtherDN A a

Multi-Site Call Transfer

In this scenario, events for which are described in the following table, DN B on Site 1 initiates a transfer for an existing call to DN C on Site 2.

Origination (Site 1)			Destination (Site 2)
DN-Based Events	Call-Based Notifications		DN-Based Events	Call-Based Notifications
B is in conversation with A. B: TInitiateTransfer to C (Site 2)
	EventCallCreated CallUUID UUID-X OriginCallUUID UUID-W ConnID c
EventDialing CallUUID UUID-X ConnID cons (c replaced by ISCC) TransferConnID orig ThisDN B OtherDN C	EventCallDataChanged CallUUID UUID-X ConnID cons ISLinkList UUID-L@'site2'
EventNetworkReached (Optional) CallUUID UUID-X ConnID cons TransferConnID orig ThisDN B OtherDN C				EventCallCreated CallUUID UUID-Y ConnID y
			EventRinging CallUUID UUID-Y ConnID ext a (y replaced by ISCC) ThisDN C OtherDN B	EventCallData-Changed CallUUID UUID-Y ConnID ext a ISLinkList UUID-L@'site1', (optional: uuid-2B)
			B: TAnswerCall()
EventEstablished CallUUID UUID-X ConnID cons ThisDN B OtherDN C			EventEstablished CallUUID UUID-Y ConnID ext a ThisDN C OtherDN B

a. For compatibility with existing solutions, ConnID is assigned at the remote site based on the value of the use-data-from option at the origination T-Server. If there exists a call with a duplicate ConnID, a new, unique ID is generated (and, for DN-based reporting purposes, the reference to the other call is passed in the LastTransferConnID attribute).

Transfer/Conference Completion

At the completion of a transfer or conference, the origination T-Server distributes the same events as in a standard single-site model. The destination T-Server may not report the completion of the transfer or conference at all, or may report it and even report on the call context change, for instance, if EPP is in effect. Transfer completion might be reported as in the table below.

For transfer completion, no explicit reporting of changes in call relations is required. EventCallDeleted with RefCallUUID implies a move of all previously attached IS-Links from call UUID-X to UUID-W.

Multi-Site Call Transfer Completion

Origination (Site 1)			Destination (Site 2)
DN-Based Events	Call-Based Notifications		DN-Based Events	Call-Based Notifications
EventReleased CallUUID UUID-W ConnID orig ThisDN B OtherDN A EventReleased CallUUID UUID-X ConnID cons TransferConnID orig ThisDN B OtherDN C EventPartyChanged CallUUID UUID-W ConnID orig PreviousConnID orig ThisDN A OtherDN C
	EventCallDeleted CallUUID UUID-X RefCallUUID UUID-W Cause Transfer CtrlParty B		EventPartyChanged (Optional) CallUUID UUID-Y ThisDN C ConnID orig PreviousConnID ext	EventCallDataChanged (Optional) CallUUID UUID-Y ConnID orig

Attaching the IS-Link Post Mortem

The following three scenarios (Simple Call Overflow, Overflow On the Intermediate Switch, and Mute Transfer With Overflow) describe instances where the IS-Link is assigned in non-standard ways, after the call has been deleted.

Simple Call Overflow

In the case of call overflow, even for a simple scenario, T-Server may discover the relation between two calls only after overflowed call has already been deleted.

Origination (Site 1)			Destination (Site 2)
DN-Based Events	Call-Based Notifications		DN-Based Events	Call-Based Notifications
EventQueued CallUUID UUID-X ConnID loc ThisDN B OtherDN A	EventCallCreated CallUUID UUID-X ConnID loc
EventDiverted CallUUID UUID-X ConnID loc ThisDN B OtherDN A	EventCallDeleted CallUUID UUID-X
	EventCallDataChanged CallUUID UUID-X ISLinkList UUID-L@‘site2'		EventQueued CallUUID UUID-Y ConnID rem (y replaced by ISCC) ThisDN C OtherDN A	EventCallCreated CallUUID UUID-Y ConnID y EventCallData-Changed CallUUID UUID-Y ConnID rem ISLinkList UUID-L@‘site1'

Overflow On the Intermediate Switch

In the case of a call being overflowed on the intermediate switch (distinct from both the original and destination), or overflowed two or more times, call information may be deleted at the transit site, even if that information still exists at the end site. The reporting is similar to the case of the simple overflow, and is shown below.

Origination (Site 1)		Transit (Site 2)		Destination (Site 3)
Call-Based Notifications		Call-Based Notifications		Call-Based Notifications
EventCallCreated CallUUID UUID-X ConnID conn-1		EventCallCreated CallUUID UUID-Y ConnID conn-2 EventCallDeleted CallUUID UUID-Y
EventCallDataChanged CallUUID UUID-X ConnID rem1 ISLinkList UUID-L1@‘site2'		EventCallDataChanged CallUUID UUID-Y ISLinkList UUID-L1@‘site1'		EventCallCreated CallUUID UUID-Z ConnID conn-3
		EventCallDataChanged CallUUID UUID-Y ISLinkList UUID-L1@‘site1' UUID-L2@‘site3'		EventCallDataChanged CallUUID UUID-Z ConnID rem3 ISLinkList UUID-L2@‘site2'

Mute Transfer With Overflow

In case of a mute transfer to a remote site, in combination with a call overflow, the relationship between the two calls may be discovered after the active call has been merged into the main call.

Origination (Site 1)			Destination (Site 2)
DN-Based Events	Call-Based Notifications		DN-Based Events	Call-Based Notifications
...	...
EventPartyChanged CallUUID UUID-W ConnID orig PreviousConnID cons ThisDN A
	EventCallDeleted CallUUID UUID-X RefCallUUID UUID-W Cause Transfer
				EventCallCreated CallUUID UUID-Y ConnID y
	EventCallDataChanged CallUUID UUID-X ISLinkList UUID-L@‘site2'		EventRinging CallUUID UUID-Y ConnID ext (y replaced by ISCC) ThisDN C OtherDN B	EventCallData-Changed CallUUID UUID-Y ConnID ext ISLinkList UUID-L@‘site1'

Client-Side IS-Link Processing

Genesys recommends taking into consideration the following principles when developing for client-side support of multi-site call-linkage discovery.

• If the same IS-Link is listed for two calls, the calls are linked together.
• An IS-Link relation is transitive: If A is linked to B, and B linked to C, then A is also linked to C.
• In order to accommodate overflow scenarios and possible network delays, you should preserve call information, even after EventCallDeleted, for a short time before purging it.
• In order to accommodate transitive call linkage, call information should be preserved as long as there are two or more active IS-Link associations with a call for which information would otherwise be purged. (For instance, avoid unlinking A and C by deleting B's call information.)
• Static storage of IS-Links can be presented in a table indexed by ISLinkUUID. In such a table, each IS-Link record provides placeholders for two calls (UUIDs) and two sites.
• For situations where only a subset of sites is visible to a client or an external routing request proves unsuccessful, the IS-Link record may remain incomplete (refer to one call only). These types of records will be discarded when the single call is purged.
• For dynamic IS-Link storage when one call is merged with another, all IS-Links should be moved to (or applied towards) the remaining call.
• An IS-Link record expires when either of two calls is purged.