Comments from IBM on CCXML LCWD (30th April 2004)

The following comments from IBM on the
April 30th CCXML LCWD are being submitted to the public mail address (as
requested by the CCXML subgroup) to ensure resolution tracking.

3.6: Session Life-Cycle 

In all the examples shown there is an  assumption that the CCXML application
will terminate the session 
by executing an <exit> element.  What is acceptable behaviour
for a system when dealing with an 
application that omits to do this?  Such applications are clearly
erroneous but would effectively 
constitute a denial of service by tieing up system resources with inactive
sessions.  Should, or is it 
acceptable, for a implementation to issue a ccxml.kill event against a
session that has no connections, 
no events in its queue, and has no outstanding <fetch> requests?

The current life-cycle descriptions do not document the possibility of
a session handling multiple 
inbound calls, the so called "master session" model.  Currently
the only documented way to handle calls 
is by initiating a new session, the so called "multi-session"
model.  IBM sees value in CCXML specifying 
the "master session" model as an accepted implementation method.
 It should be possible to configure 
a CCXML implementation to service inbound calls from a number of telephony
resources via a single 
session.  For applications such as simple inbound call to dialog routing
as commonly implemented on 
IVRs the "master session" model is a simple and efficient mode
of operation.  We acknowledge that for 
more complex application the use of the full range of the CCXML constructs
including the state variable 
and other document level variables is required and in this case a "multi-session"
model is appropriate.  
Restricting the specification to just the "multi-session" model
imposes additional computation overhead 
on simple applications. 

9.4.5.4: Errors While Handling Error Events 

The text as it stands seems somewhat draconian.  It is conceivable
that a CCXML document could 
attempt to recover from an error condition but encounter another error
condition in the process but 
still recover.  As specified the interpreter must terminate for any
error encountered while dealing with 
an error event.  We would suggest this section be revised to suggest
termination of a CCXML session if 
a loop is detected i.e. a recurrent identical error condition or detectable
pattern, rather than any error. 

10.2.1: Connection State 

The state diagram only shows the availability of media streams in the CONNECTED
state.  This does not 
allow for the early media situation where media flows can occur while the
connection is in alerting or 
transitioning between alerting and connected. 

11: Complex Examples 

The CCXML examples are unreadable if the specification is printed as the
left-hand end of many lines is 
truncated. 


Cheers
Dave

David S. Renshaw MBCS
WebSphere Voice Architect
IBM Pervasive Computing division
tel: +44 1962 815517 fax: +44 1962 817999