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

Figure 2. Blueworx Voice Response signaling model

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.