data that can be used during execution of processes
from this layer is the current time.
4.4 Applications
A behavior of additional call handling applications
(e.g. Interactive Voice Response, Voice Mail, Auto
Attendant) may be different depending on an ANI
number, a time, data, a profile of a caller and so on.
A management and administration of the system and
a login and logout functionality for users also creates
context that can be used by applications.
Because endpoints provide an access to function-
alities and information anytime and anywhere, they
can be treated as pervasive devices. As a result, the
layered model presented in Figure 1 can be divided
into a pervasive part, which consists of the endpoints
layer and a ubiquitous part, which consists of the reg-
istry, the call routing and the applications layer. That
reflects the nature of enterprise telephony systems,
where endpoints are distributed among users (they are
physically close to them and each user has his own
endpoint) and the rest of the system is logically cen-
tralized but accessible anywhere users need.
From the set of requirements presented in Table 1,
last four of them regard context-awareness. To deliver
a system which meets those requirements it is nec-
essary do go through the process of its deployment
which mainly includes design and configuration.
5 DESIGN AND
CONFIGURATION APPROACH
FOR CONTEXT-AWARE VoIP TS
A deployment of a context-awareVoIP TS can be sys-
temized with the usage of the layered model presented
in Figure 1. A resulting approach is organized accord-
ing to the Agile method. Firstly, the requirements
for a new VoIP TS deployment have to be assigned
to the particular layers of the TS model. Next, each
of the requirements needs to have assigned a priority
expressing its importance from the user perspective.
Based on the analysis, for each requirement there can
be assessed a time that is needed to prepare a nec-
essary configuration. The conducted analysis should
include a necessary design of a part of the VoIP TS
(which will satisfy the requirements) as well as inter-
ferences with the already deployed parts of the sys-
tem. The design that regards context-aware require-
ments should include defining a situation (particular
context) to which appearance in the space the VoIP
TS will react, and also which configuration changes
in the TS will take place. Based on the priorities, as-
sessments and time constraints the deployment pro-
cess can be divided into separate iterations. After
each iteration is completed, there is delivered a use-
ful from the user perspective functionality that can be
tested and accepted. That also allows users to intro-
duce new or correct previously specified requirements
along with the progress of the deployment, which is a
common situation during VoIP TS deployments. The
organization of the sample deployment which resulted
from implementing described approach is presented
in Table 2 (context-aware requirements are marked
with ’(c)’).
Comparing to the initial set of requirements (see
Table 1) a one additional requirement has been for-
mulated by users. After they used a partly deployed
system (delivered in the first iteration) users decided
that when someone logs out from a workstation, an
office phone should switch to a stand-by (idle) mode
and should require an authorization for making calls.
That requirement (with id 11(c)) appeared during the
second iteration and its realization has been planned
for the third iteration. Within each iteration after the
design is completed, a necessary configuration needs
to be prepared.
VoIP TS systems may need to behave differently
depending on their (and their objects) context. Hence,
a particular object (apart from the initial configuration
needed to satisfy context-unaware requirements) may
need to be reconfigureddepending on context data de-
livered by sensors (i.e. endpoints - see Section 4 or
other sources). Nowadays, such context-aware recon-
figuration can be based on a limited set of parameters
(most often a time and a location). However, VoIP
TS systems can be deployed in different environments
and the definition of a context can change between
deployments. That is why a VoIP TS should have a
capability of defining a context and based on it - re-
configuring its particular objects. Context data can be
sent by sensors using a SIP protocol (Pan et al., 2003)
(in a form of additional headers) which is widely used
in the telephony signalization.
Regarding an aspect of context-awareness, VoIP
TS systems can be modelled using the CAA model in-
troduced in (Krawczyk and Nasiadka, 2011). As such
their architecture can be extended with components
needed to execute CAA applications. Those compo-
nents are responsible for context analysis, commu-
nication with sensors, knowlegde base management
and changing configuration. The implementation of
such extension for a particular VoIP TS deployment
has been described in the next section.
DesignandConfigurationofContext-awareVoIPTelephonySystems
45