CISCO-CVP-MIB Table View

The service table is a list of Customer Voice Portal (CVP)
functional services.  A CVP solution includes a collection
of interconnected functional services, each of which perform
a specific, necessary function of the CVP application.  This
table enumerates and lists all CVP functional services
installed and configured on this server.  A single server is
permitted to have multiple functional services of a different
type, but also multiple services of the same type (although
far less likely).
          
The service table is indexed by a unique numeric identifier
for each functional service.  This service index is
arbitrarily assigned by the SNMP agent.  These same index
values are used in the individual service information tables,
thus, the individual service information tables have a sparse
dependency relationship with this table.
          
The SNMP agent constructs the service table at startup based
upon static data saved in a properties file.  Since services
can only be configured while the CVP application is stopped,
service table entries cannot be added to or deleted from the
table at run time.  Object values can and will be modified by
the agent but not the management station.  All objects in
this table are read-only to the management station.

The SIP service table lists each Customer Voice Portal SIP
service configured on this server.  The CVP SIP service is a
software module which always resides in the CVP Call Server.
          
The CVP SIP service is a SIP Back-to-Back User Agent (B2BUA).
On the front end, it supports two SIP call legs, one incoming
and one outgoing.  This service does not terminate RTP flows;
it only deals with SIP messages.  On the back end, the SIP
service implements the (GED-125) Service Control Interface
(SCI) to the Cisco Intelligent Contact Management (ICM)
application for call control functions only (no VRU scripts).
          
The purpose of a B2BUA is to act as an active intermediary
for a call, communicating with both the source and the
destination legs of the call, and providing 3rd party call
control capabilities on behalf of a routing engine (such as
the ICM contact router).  Because it must track the call
throughout its life, it becomes a key source of call-level
reporting data and a natural place for moderating call
switching resources.
          
Generally speaking, a SIP B2BUA is two User Agents (UAs).
The device receives incoming calls in one UA and immediately
creates an outgoing call via its other UA.  Thereafter, all
SIP messages from either one are forwarded to the other.
What makes it useful is the fact that it puts ICM in between
the two legs.  On incoming calls, it asks the ICM where the
outgoing call should be addressed.  Once the call has been
delivered, ICM has the opportunity to end the outgoing leg
and reconnect it to a subsequent destination.  In practice,
there will typically be a delivery to the subsequent agents
(call center agents - a human resources tasked with answering
inbound calls and providing specific services) or back to
the VRU leg.
          
The SIP service table has a sparse dependent relationship
with the (generic) ccvpService table.  The service index acts
as the primary index, relating the entry to the corresponding
entry in the ccvpService table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information entries cannot be
added to or deleted from the table either by the agent or the
management station while the application is running.  The
agent will update service information table objects as their
values change when the application is running.  All objects
in this table are read-only to the management station.

The H.323 Service table lists each Customer Voice Portal
(CVP) H.323 service configured on this server.  This service
is a software component which always resides on the CVP Call
Server.  The CVP H.323 service interacts with the CVP IVR
service to relay call arrival, departure and transfer
instructions between it and other H.323 devices.
          
The CVP H.323 service is a legacy service used only in H.323-
based deployments.  Although this service started as a true,
albeit incomplete, voice browser, its strength was its
ability to effect complicated H.323 call control activities
with the Gateway and the Cisco Call Manager.  Over time, the
VXML Gateway's IOS voice browser supplanted it as a voice
interaction device and call control became its main focus.
          
SIP is still a young protocol compared to H.323 and there are
still certain capabilities which either the gateway, the Call
Manager or the protocol itself does not yet support.  Users
who require these capabilities, as well as those who wish to
upgrade without switching from H.323 to SIP will therefore
continue to use the CVP H.323 service in place of the CVP SIP
service.
          
This table has a sparse dependent relationship with the
Service table.  The service index acts as the primary
index, relating the entry to the corresponding entry in the
Service table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information table entries
cannot be added to or deleted from the table either by the
agent or the management station while the application is
running.  The agent will update service information table
objects as their values change when the application is
running.  All objects in this table are read-only to the
management station.

The IVR Service table lists each Customer Voice Portal
Interactive Voice Response service configured on this server.
Each entry in the table defines a separate IVR service; a
single server is permitted to have multiple IVR services.
The CVP IVR service is a software module which always resides
int he CVP Call Server.
          
The CVP IVR service is responsible for creating the VXML
pages which implement the CVP Microapps based on 'Run Script'
instructions received from the ICM. (The 'Run Script'
instruction is part of the Service Control Interface offered
with the GED-125 messaging protocol.)
          
The service function as the VRU leg in ICM parlance and calls
must be transferred to it from the SIP service in order to
execute microapps.  The VXML pages created by this module are
sent to the VXML Gateway to be executed.
          
In legacy deployments only -- those which use H.323 instead
of SIP -- the CVP IVR service can act as the switch leg as
well.  The deployment includes a CVP H.3232 service which
interacts with the CVP IVR service for call control
activities.  Calls still need to be transferred to a VRU leg
before microapps can be executed, however, in legacy
deployments, that transferred leg may end up using the same
CVP IVR service as the switch leg.
          
The CVP IVR service plays a significant role in implementing
CVP's native failover mechanism -- those capabilities which
can be achieved without a Content Services Switch -- for
Media Servers, ASR/TTS Servers and CVP VoiceXML Servers.  Up
to two of each such server are supported and the CVP IVR
service orchestrates retries and failover between them.
          
This table has a sparse dependent relationship with the
Service table.  The service index acts as the primary
index, relating the entry to the corresponding entry in the
Service table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information table entries
cannot be added to or deleted from the table either by the
agent or the management station while the application is
running.  The agent will update service information table
objects as their values change when the application is
running.  All objects in this table are read-only to the
management station.

The ICM Service table lists each Customer Voice Portal
ICM service configured on this server.  Each entry in the
table defines a separate ICM service.  The CVP ICM service is
responsible for all communication between CVP components and
the Intelligent Contact Management (ICM) application.
          
The CVP ICM service implements the GED-125 Service Control
Interface (SCI) protocol, and sends and receives messages on
behalf of the CVP SIP service, the CVP IVR service, and the
CVP VoiceXML service.  Users do not explicitly install the
CVP ICM Subsystem; it is installed and activated
automatically in the CVP Call Server and the CVP VoiceXML
Server.  This service is visible at the CVP Operations
Server, however, since it does require a small amount of
configuration.
          
This table has a sparse dependent relationship with the
Service table.  The service index acts as the primary
index, relating the entry to the corresponding entry in the
Service table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information table entries
cannot be added to or deleted from the table either by the
agent or the management station while the application is
running.  The agent will update service information table
objects as their values change when the application is
running.  All objects in this table are read-only to the
management station.

The Reporting service table lists each Customer Voice Portal
reporting service configured on this server.  The CVP
Reporting Server houses the CVP Reporting service as well as
a database management system to persist data.
          
The CVP reporting service receives reporting events from the
CVP IVR service, the CVP SIP service, and the CVP VoiceXML
service.  The service is deployed together with a database
management system and it transforms and writes this reporting
data into that database.  The database schema is prescribed
by the CVP product, but it is an open schema in that
customers may develop custom reports based on it.
          
There can only be one CVP Reporting Server in a deployment.
This does not represent a single point of failure however,
because data safety and security are provided by the database
management system, and temporary outages are tolerated due to
persistent buffering of information on the source components.
          
This table has a sparse dependent relationship with the
Service table.  The service index acts as the primary index,
relating the entry to the corresponding entry in the Service
table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information table entries
cannot be added to or deleted from the table either by the
agent or the management station while the application is
running.  The agent will update service information table
objects as their values change when the application is
running.  All objects in this table are read-only to the
management station.

The Voice XML Service table lists each Customer Voice Portal
Voice XML service installed and configured on this server.
          
The CVP VXML server includes both the CVP VXML service and
the VXML server software that executes complex IVR
applications by exchanging VoiceXML pages with the VXML
Gateway?s built-in voice browser.  Like almost all other CVP
product components, it runs within a J2EE application server
environment such as Tomcat, and many customers add their own
custom-built or off-the-shelf J2EE components to interact
with back-end hosts and services.  CVP VoiceXML Server
applications are written using the CVP VoiceXML Studio, and
deployed to the Server for execution.  They are invoked on an
as-needed basis by a special microapp which must be executed
from within the ICM routing script.
          
The VXML Server may also be deployed in a standalone
configuration ?- one which includes no ICM components.  In
this model, applications are invoked as a direct result of
calls arriving in the VXML Gateway, and a single
post-application transfer is allowed.  Users may add the CVP
VXML service software.  This affords standalone applications
the additional ability to forward reporting events to a CVP
Reporting Server, and to make ancillary routing requests and
exchange call context information with an ICM if one is
present.  However, the integration with ICM is nominal.
          
This table has a sparse dependent relationship with the
Service table.  The service index acts as the primary
index, relating the entry to the corresponding entry in the
Service table.
          
The SNMP agent constructs this table at startup.  Since
services can only be added or deleted when the CVP
application is stopped, service information table entries
cannot be added to or deleted from the table either by the
agent or the management station while the application is
running.  The agent will update service information table
objects as their values change when the application is
running.  All objects in this table are read-only to the
management station.