Modularity is the ability to split a VBVoice application into separate, co-operating applications, distributed across a network. Large applications can be partitioned into smaller modules, where each is a separate executable. In an ASP-like environment, a series of tenant applications use modularity to share voice hardware. Because the tenant applications are separate executables, they can be stopped and started independently.
Modularity defines two types of applications: masters and slaves.
A master application is a VBVoice application with one or more SlaveStart controls. The master answers calls and performs all telephony and media processing on behalf of slaves. It uses a SlaveStart control to transfer execution of the phone call to a slave application. The master stays in the SlaveStart control for the entire time the slave has the call. When the slave is done, the master regains control of the call and can continue processing itself or pass it to other slaves.
Masters and slaves can start in any order. The only requirement is that the slave needs to be running by the time the master executes the SlaveStart control.
TTS is done on the master. When a slave plays a TTS phrase (SayText), the TTS Speaker property is taken from the master application and not the slave.
ASR is done on the master. When a slave does speech recognition, the design-time settings are taken from the master application and not the slave.
A slave is a VBVoice application whose VBVFrame property SlaveType is set to Yes. Multiple slaves can run on a single machine. Slaves can be distributed across multiple machines and may be co-resident (i.e. run on the same machine) with the master.
When VBVoice starts a slave application, the regular voice interface DLL (such as vbvdlg32.dll) is not used. Instead a special slave DLL is loaded. This slave DLL does not talk to voice hardware: it forwards all requests over TCP/IP to the master. This allows the slave to run on a different machine from the master.
A slave application looks like a regular VBVoice application. It has a LineGroup control where all channels sit until a call arrives. When a call arrives, the channel exits the LineGroup control and proceeds through the other controls in the call-flow. Execution continues until either a disconnect occurs or a SlaveEnd control is executed.
A slave requires a unique name (unique from all other slaves). It is set by the VBVFrame property SlaveName. The slave name is used by the master to invoke a particular slave. The master does not need to know which machine the slave is running on: an additional VBVoice component called the arbiter tracks slaves and their IP addresses.
Set the SlaveType property of VBVFrame to Yes
Set the SlaveType to Auto
This causes the application to use a setting in vbvoice.ini to determine if it should be a slave or not. file. If the [Voicecard] setting type equals "Slave" then the application is a slave. Auto is useful when the application needs to be switched into a slave after it has been compiled.
The slave needs to run enough channels to process the maximum number of calls the slave may receive. The LineGroup control in a slave application determines how many channels will be run.
EXAMPLE:
Setting the LinesInGroup property to "1-24" would mean 24 channels are run in the slave.
Although slave channels are not tied to voice hardware, they do consume computer resources. Slaves should not run more channels than needed.
There is no fixed relationship between master and slave channels. A call to channel X in the master may get processed by a different channel number in a slave, because with multiple masters there are multiple channel 1s (one in each master). A slave therefore cannot always execute on the same channel as the master.
When a call is passed to a slave, a slave virtual channel is selected somewhat randomly, but generally it is the one that has been waiting the longest in the LineGroup control. For example, if there are 2 channels available in a slave, and both go OnHook and become available after each call, a series of new calls might be handled by the channels in the following order: ch2, ch1, ch2, ch1...etc. Even when all the lines are available, there is no guarantee that the first channel will be used. This is important to be aware of when using certain methods in the slave application (e.g. LineGroup.BridgeChannelToChannel(currentChannel, otherChannel) ).
Data can be passed from master to slave and vice versa. To pass data to a slave, the master sets the SlaveStart ISharedData or SharedData properties. These data strings are passed to the slave along with the call. They appear in the slave as VBVFrame Transfer properties, named SharedData1, SharedData2, ..., SharedData5.
If the slave modifies these transfer properties, the changed values are sent back to the master when the slave ends. The master can extract the returned values from the SlaveStart.SharedData properties after the SlaveStart control finishes.
The simplest approach to developing modular applications is to develop a slave application first as an ordinary VBVoice application. Use a machine with a voice card and any TTS and ASR engines that are required. When it is ready to integrate with the master, switch the application into a slave.
|
Read About: |
|
|
|
|
|
|
|
|
|
|
|
|
Scaling up modular applications: multiple masters and duplicate slaves |