Device control protocols are master/slave protocols where every detail of
the device operation is controlled from a central server. Master/slave proto-
cols are also sometimes called “stimulus protocols,” since every event or stim-
ulus experienced by the terminal must be relayed to the controller using the
protocol. In this model, every event (such as a hook flash), has to be reported
to the central controller, and every action of the device has to be controlled
(such as how to display a number or a message). All this activity generates a
large and mostly unnecessary amount of network traffic between the GC and
all the MGs (not shown in Figure 19.1a) compared to the traffic that would be
required if the MG would have its own control intelligence.
How does the controller know if the device has a display at all? The answer
is, it does not know, unless it has been preconfigured with a so-called package
(Figure 19.1b) that is written for that particular device (such as, for example,
for a specific phone model that may or may not have a display with certain
capabilities).
Since the package in the control device has to know every detailed feature of
the controlled device, which is also dependent on various product versions, it
is practically impossible to have them made by different and possibly compet-
ing vendors, in spite of the standard control protocol used between the con-
troller and the device.
In the case of media gateways, packages have to be written and provisioned,
depending on the particular circuit switch network signaling of the media
gateway such as channel-associated signaling (CAS), Q.931, and SS7 in its var-
ious national variants. This forced bundling of the controller with all con-
trolled devices seems to be the right prescription for vendors to lock in their
customers, the service providers.
The central control in master/slave protocols is not scalable.
This is in stark contrast to the Internet model, where the implementation of
networked devices does not need to be known by other devices to interwork
and, even more, where interworking devices have to be developed in an inde-
pendent manner by competing designers around the world. You can commu-
nicate with an Internet-connected device without caring if, at the other end,
there is a palmtop computer or a powerful server farm, or some mainframe
computers in a data center. Also, when using FTP, e-mail, or browsers, no con-
sideration has to be given how the remote IP device is configured. Device con-
trol protocols also have no notion of redirection, and a controlled device
cannot refuse a request (unless it reports an error) or offer alternate destina-
tions to honor a request.
SIP Component Services 319