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