Call Models and Flows
Legend
All parties shown in a call scenario, except where stated explicitly, are considered internal and are monitored by T-Server. If one or more external parties participated in the call, the following apply:
- T-Server will not distribute any events to the external (nonmonitored) party.
- T-Server may not have any information about the nonmonitored party, so its reference may not be specified.
The following diagram illustrates a basic call model.
Activities like conference and transfer can be performed to an existing multi-party call (a conference call). When so, Party A is considered a "complex party" and the following apply:
- Events assigned to Party A, as shown in call scenarios, are sent to every party of "complex party."
- Reference to Party A in AttributeOtherDN are not present.
This is also represented in the following tables.
| PARTY A (complex) | PARTY C |
|---|---|
| EventPartyChanged ConnID 1 |
EventPartyChanged ConnID 1 |
| PARTY A0 | PARTY A1 | PARTY C |
|---|---|---|
| EventPartyChanged ConnID 1 |
EventPartyChanged ConnID 1 |
EventPartyChanged ConnID 1 |
Since T-Library is a superset of functions, not every scenario described in this document is supported by every type of switch. For more details, see the T-Server Deployment Guide that applies to your T-Server/switch pair.
When more than one event is presented in one table cell, the order in which the events are distributed may vary.
Attributes ThirdPartyDN and ThirdPartyDN Role specify DNs to which two-step operations are initiated and completed.
A call is considered to be queued until either EventDiverted or EventAbandoned regarding the queue is generated.