Comments on CCXML specification

Hello,

We would like to suggest a few modifications and improvements of the 
CCXML specification that are motivated by our and our customers 
experience with building real-world CCXML applications. We believe that 
the suggested changes can be generally useful. In the same time, they 
are simple to incorporate into the specification and to implement.


1) Attribute 'event' of the <transition> tag

In some situations, several events are handled the same way. For 
instance, after receiving connection.disconnected or connection.failed 
the application typically exits. Since it is not possible to specify 
more than one event in one transition (wild-cards are not always 
sufficient) it is necessary to use more transitions where event name is 
the only difference.

Our suggestion is to allow the event attribute to specify more than one 
value just as it is allowed for the state attribute:
"More than one value may be specified, separated by whitespace."


2) Named conference

It would be useful in some applications to distinguish situations when 
we really create a new conference and when we just get id of an existing 
conference with the given name. Sometimes it is necessary to perform a 
specific action when a conference is newly created.

Our suggestion is to add an attribute carrying this information to the 
conference.created event. Analogously, we suggest to add an attribute to 
the conference.destroyed event that will state that the conference was 
really destroyed.


3) Attribute 'info' in the conference.created and conference.destroyed 
events

Our idea to work around the problem (2) was to use the platform 
dependent attribute 'info' in the conference.created event. However, in 
contrast to the connection.* events there is no such attribute in 
conference.created nor conference.destroyed events. Is there any reason 
for this?

Our suggestion is to add attribute 'info' to the conference.created and 
conference.destroyed events with the same meaning this attribute has in 
connection.* events.


4) Number of conference participants

It is not possible to get information about the total number of 
participants in a conference. The 'bridges' property of the Conference 
object contains only the identifiers of connections/dialogs within the 
current session. Connections/dialogs owned by other sessions and joined 
to the same conference are not visible. So it is not always possible to 
find out whether there are more participants (and how many) in the 
conference.

Our suggestion is to add a property to the Conference object that would 
show the total number of connections/dialogs joined to the conference.

Best Regards,
Petr Kuba

-- 
    Petr Kuba, Project Manager
    OptimSys, s.r.o
    kuba@optimsys.cz
    Tel: +420 541 143 065
    Fax: +420 541 143 066
    http://www.optimsys.cz

Received on Friday, 18 September 2009 09:58:01 UTC