This section provides detailed sequence flows for the most common scenarios supported by HIS.  The flows illustrate the most likely order of actions by an agent and the queries, requests, responses, and events that take place as a result.

This scenario describes the flow of messages and events related to the startup of the processor bridge.  This only occurs as a result of HIS starting up and being initialized.

1. HIS creates a new instance of the processor bridge based on the information provided in the HIS configuration.  When created, the processor bridge instance is provided any processor type specific information included in the configuration.

2. The processor bridge notifies HIS that it is starting.

3. In this case, the processor bridge is configured to start a new local message broker.  This broker will be used to facilitate the bridge protocol.  The bridge could have been configured to use an external message broker instead.

4. The processor bridge connects to the message broker and sets up the processor control link.  It then waits for a Bridge Client to connect to the message broker.

5. The Bridge Client connects to the message broker and registers with the control link topics.

6. The message broker notifies the processor bridge that a Bridge Client has been registered with the control link.

7. The processor bridge sends a server status request to the new Bridge Client to determine what state the client is in.

8. When the processor bridge receives the status update, it notifies HIS of the new status.

9. The processor bridge queries the Bridge Client for its capabilities information.

10. The Bridge Client returns its capabilities.

11. The processor bridge notifies HIS of its capabilities.

12. If the server’s status is started, the processor bridge is now ready to accept new agent sessions.  Otherwise, the processor bridge waits for the Bridge Client to enter the started status.

13. The processor bridge will continue to listen for changes to the Bridge Client’s server status and update HIS as the changes occur.

Inbound Call – Setup

This scenario describes the message flow between HIS and the Bridge Client for an inbound telephony call.

1. An agent is selected to receive the new inbound call by the CTI routing engine and that call is delivered to the agent’s phone.

2. The Bridge Client receives an event from the CTI indicating a new call is ringing on the agent’s phone.

3. The Bridge Client sends a “channel.interaction.available” event on the corresponding telephony channel link that includes the native id for the telephony interaction.

4. HIS creates a new internal Interaction object and JMS link for the new interaction.

5. HIS sends a “channel.request.createinteraction” request to the Bridge Client over the telephony channel link.  This request includes the original native id provided in the “channel.interaction.available” event, the internal HIS id for the interaction, and topic information related to the new interaction JMS link.

6. The Bridge Client creates any internal objects needed to represent the interaction and registers with the interaction link.  If successful, the Bridge Client sends a SUCCESS response to the “channel.request.createinteraction” request over the telephony channel link.

7. Once a SUCCESS response is received, HIS begins to initialize the new interaction object.  A “interaction.query.init” query is sent to the Bridge Client over the new interaction link.

8. The Bridge Client determines the state of the interaction and builds a XML response document that contains the state information as well as a native id for the primary conversation call leg.  Note: Not all CTIs have unique identifiers for individual call legs.  If this is the case, the Bridge Client must provide a value that is unique for each conversation within a single interaction.

9. The Bridge Client sends a SUCCESS response to the “interaction.query.init” query that includes the response xml document.

10. HIS creates a new internal Conversation object and JMS link for the new conversation.

11. HIS sends a “interaction.request.createconversation” request to the Bridge Client over the interaction link.  This request includes the original native id and internal HIS id for the conversation as well as the topic information for the conversation link.

12. The Bridge Client creates any internal objects needed to represent the conversation and registers with the conversation link.  If successful, the Bridge Client sends a SUCCESS response to the “interaction.request.createconversation” request over the interaction channel.

13. Once a SUCCESS response is received, HIS begins to initialize the new conversation object.  A “conversation.query.init” query is sent to the Bridge Client over the conversation link.

14. The Bridge Client determines the state of the conversation and any parties (other than the agent) active within the conversation and formats the information into an XML document.

15. The Bridge Client sends a SUCCESS response to the “conversation.query.init” query that includes the XML content to HIS over the conversation link.

16. At this point the agent’s phone is ringing and the media bar enables the answer button to allow the agent to accept the phone call.

Inbound Call – Call Answered at MediaBar

The answering of an inbound phone call can be initiated by the MediaBar in one of two ways.  The interaction can be accepted or the conversation can be answered.  Implementations of this protocol must support both ways of initiating the answer of an inbound phone call.  The following diagram shows both mechanisms:

The flow of messages is the same once the answer/accept is initiated:

An inbound phone call can be answered at the MediaBar either through the agent manually clicking on the Answer/Accept button or the MediaBar will automatically request the answer if the AutoAnswer option is enabled.  The flow of events is the same in both cases.

1. The MediaBar requests that HIS answers the pending inbound phone call.

2. HIS sends a “conversation.request.answer” request to the Bridge Client over the conversation link.

3. The Bridge Client initiates the answer with the CTI.  If the operation is successfully initiated (not necessarily completed), the Bridge Client sends a SUCCESS response to the “conversation.request.answer” request over the conversation link.

4. Once the Bridge Client has confirmation of the phone call being answered, it sends a “conversation.started” event over the conversation link.

5. Once the “conversation.started” event is received by HIS, it automatically places the interaction into the started state as well.  This makes sending the “interaction.started” event by the Bridge Client unnecessary.  The Bridge Client may choose to send this event anyways without causing any issues.

6. The Bridge Client must also send a “conversation.talking” event following the “conversation.started” event to indicate that the call is in the TALKING state and not in the HELD state.