Jump to: navigation, search

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.
This page was last modified on March 21, 2018, at 17:48.

Feedback

Comment on this article:

blog comments powered by Disqus