| Scenario |
Type |
Detail |
| 1) The user detail comes into the CTI |
Basic Path |
An assumption, at this point, is that all user detail (AgentID, Password, and Address) is valid. There may be two scenarios that we must design for:
a) Assumes No Authentication: Optimistic - all data are valid (via XML schema pre-processing at the client) and we allow the Device (switch) to manage authentication and verification. This also assumes that the CTI does not want to maintain or remember over time any incoming Agent detail.
b) Assumes Some Authentication: Pessimistic - we check for data validity. In addition, we check whether or not we have this detail currently in our CTI domain (this can also be managed at the pipeline).
Another collateral issue is: how do we want to Collect information: do we want to Administer the Agent/Address, etc. detail OR do we want to build it over time, e.g. doing a Lazy lookup and IF NOT FOUND THEN ADD the detail (perhaps after the Device has validated the detail). |
| 2) The Domain Manager (system) determines whether the CTI (provider) is available. |
Basic Path |
The Domain Manager (aka DynaRep) is the complete application domain that consists of the ClientPipeline, the DevicePipeline, and the CTI application. |
| 3) The Domain Manager provides a Result (Response) to the User |
Basic Path |
This Result or Response contains the condition of the Connection request. In addition, it can also contain the "capabilities" of the Domain, which are all of the services available to the User (depending upon authorization). |
| 3.1) Generate Domain connection Event |
Basic Path |
This substep generates an event of the connection, carrying along all salient data. This ties back to the fundamental assumptions from Step 1 regarding how we store/remember/administer incoming Agent/Password/Address detail. |