The Blueworx Voice Response signaling model is based on the CallPath Services Architecture,
as defined in the CallPath Services
Programmer’s Reference manual
(GC31-6824). The main difference is that Blueworx Voice Response does not implement the Routing
state associated with automatic call distributors (ACDs).
Figure 1. CallPath signaling model
![This signaling model begins and ends at Idle state. From Idle state the route passes in one direction through Pending state to Connected state, and in the other through Routing state to Alerting state and beyond. All states are shown returning directly to Idle state.](./cpsigmod.gif)
Figure 2. Blueworx Voice Response signaling model
![This signaling model begins and ends at Idle state. From Idle state the route passes in one direction through Off-hook state to Connected state, and in the other through Ringing state to Connected state. All states are shown returning directly to Idle state.](./dtsigmod.gif)
There are differences in the responsibilities of the signaling process,
depending on whether it is implementing a common channel signaling protocol
or one of the exchange data link protocols:
- Within Blueworx Voice Response, a common channel signaling process is required to take
full responsibility for all the signaling on its supported trunks.
- The situation for exchange data link signaling processes is different.
With exchange data link protocols, some of the signaling information is carried
on the data link, while the remaining signaling is carried on the trunk just
as in channel associated signaling. Exchange data link signaling processes
are responsible for only some of the signaling for the channels they
control.