Re: Comments on CCXML specification - [cc] ISSUE-635 ISSUE-636 ISSUE-637 ISSUE-638

Peter,

I have broken this into 4 issues that will be tracked individually.  
They are listed below and I will send out follows to them individually.

> 1) Attribute 'event' of the <transition> tag - ISSUE-635

> 2) Named conference - ISSUE-636


> 3) Attribute 'info' in the conference.created and  
> conference.destroyed events - ISSUE-637

> 4) Number of conference participants - ISSUE-638


	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Sep 18, 2009, at 11:57 AM, Petr Kuba wrote:

> 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 Thursday, 22 October 2009 09:38:00 UTC