Cisco Cisco Unified Customer Voice Portal 11.0(1) Release Note
C
HAPTER
5:
C
ALL
E
ND
A
CTION
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
25
Chapter 5: Call End Action
VXML 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:
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
that yield a hang-up, or places in the application when the call’s purpose is over.
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 VXML
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.
using telephony switching equipment, removing the voice browser (and hence VXML
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 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.
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.
•
VXML Server times out a session. This occurs only rarely, it would be seen only when some
error prevented VXML 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 VXML Server
cannot determine which call that request was supposed to be for.
error prevented VXML 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 VXML 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 VXML Server to be notified that the call ended. This functionality is described in
more detail in the chapters on custom elements.
ability to invalidate the session for situations where some process ends the call that would not
prompt VXML 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 (hangup, 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 (hangup, call transfer, etc.) This is useful for activities such as
creating CDR records which must list everything a caller did.