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:
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
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.
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
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
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.
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.
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.
A unique feature of the
call end action is to optionally send back a final VoiceXML page to the voice
browser. Some voice browsers will actually interpret a VoiceXML page sent back
in response to a request triggered by a disconnect or hang-up event. Since the
caller is no longer interacting with the IVR, this page would obviously only be
useful for limited functionality that had nothing to do with interacting with
the caller, such as executing
This final page applies only to when the caller hangs up on the
application or the application hangs up on the caller.