Cisco Cisco Unified Customer Voice Portal 10.0(1) Guía Del Desarrollador
C
HAPTER
5:
C
ALL
E
ND
A
CTION
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
22
Chapter 5:
Call End Action
Unified CVP VoiceXML Server can be configured to run code once a call has ended. Unlike the
call start action, the call end action can occur at any time in the call and there are several
different situations that would trigger the call end action. The following lists those situations:
call start action, the call end action can occur at any time in the call and there are several
different situations that would trigger the call end action. The following lists those situations:
The caller hangs up normally.
The application hangs up on the caller. This includes any errors that are caught by the system
The application hangs up on the caller. This includes any errors that are caught by the system
that yield a hang-up, or places in the application when the call’s purpose is over.
A blind telephony transfer takes place. Blind transfers connect the caller with the party called
using telephony switching equipment, removing the voice browser (and hence the
VoiceXML Server) from the calling context. Even though the physical phone call continues,
the role of the automated system ends and so for it, the call has ended. Note that the
availability of blind transfers is determined by the voice browser’s functionality and network
setup.
VoiceXML Server) from the calling context. Even though the physical phone call continues,
the role of the automated system ends and so for it, the call has ended. Note that the
availability of blind transfers is determined by the voice browser’s functionality and network
setup.
The application performs a transfer to another Cisco Unified CVP application. This is not a
telephony transfer, but the results are very similar. Since the call leaves the source
application, it is considered the end of the “call” to that application.
application, it is considered the end of the “call” to that application.
The VoiceXML Server times out a session. This occurs only rarely, it would be seen only
when some error prevented the VoiceXML Server from receiving a request in the middle of a
call and it waited a certain amount of time before timing out the session. This could be due to
a voice browser going down or if the request coming from the voice browser is malformed
and the VoiceXML Server cannot determine which call that request was supposed to be for.
call and it waited a certain amount of time before timing out the session. This could be due to
a voice browser going down or if the request coming from the voice browser is malformed
and the VoiceXML Server cannot determine which call that request was supposed to be for.
The session is invalidated by a custom element. Standard and configurable elements have the
ability to invalidate the session for situations where some process ends the call that would not
prompt the VoiceXML Server to be notified that the call ended. This functionality is
described in more detail in the chapters on custom elements.
prompt the VoiceXML Server to be notified that the call ended. This functionality is
described in more detail in the chapters on custom elements.
The call end action can be implemented with either the Java API or the XML API. Unlike the
call start action using the XML API, the call end action does not have an option to perform it in
the background. In fact, one need not worry about performing time consuming tasks in the call
end action because it will not affect the performance of the call since it has ended. One must still
be careful not to perform tasks that maximize CPU usage since that would aversely affect the
handling of other calls.
call start action using the XML API, the call end action does not have an option to perform it in
the background. In fact, one need not worry about performing time consuming tasks in the call
end action because it will not affect the performance of the call since it has ended. One must still
be careful not to perform tasks that maximize CPU usage since that would aversely affect the
handling of other calls.
Like the call start action, the call end action can modify the session such as creating session data
or changing the default audio path, though these actions would not make sense as there is no
more call flow to visit. The call end action can access everything that occurred within the call,
including how the call ended (hang-up, call transfer, etc.) This is useful for activities such as
creating CDR records which must list everything a caller did.
or changing the default audio path, though these actions would not make sense as there is no
more call flow to visit. The call end action can access everything that occurred within the call,
including how the call ended (hang-up, call transfer, etc.) This is useful for activities such as
creating CDR records which must list everything a caller did.