Comments on CCXML specification

[Petr Kuba]

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@...
    Tel: [phone]
    Fax: [phone]
    http://www.optimsys.cz

[RJ Auburn]

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:[phone]

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@...
>   Tel: [phone]
>   Fax: [phone]
>   http://www.optimsys.cz
>

[RJ Auburn]

Petr:

>> 4) Number of conference participants - ISSUE-638
>>
>> 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.

This will be considered asa feature request for CCXML 1.1.

Best regards,

        RJ


---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

[RJ Auburn]

Petr:

>> 1) Attribute 'event' of the <transition> tag - ISSUE-635
>>
>> 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."

This sounds like a great idea and will be considered as a feature  
request for CCXML 1.1.

Thanks for the great feedback.

Best regards,

        RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

[RJ Auburn]

Petr:

>> 2) Named conference - ISSUE-636
>>
>> 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.

I agree this would be helpful for a number of applications. We will  
look at adding this in CCXML 1.1.

Best regards,

        RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

[RJ Auburn]

Petr:

>> 3) Attribute 'info' in the conference.created and  
>> conference.destroyed events - ISSUE-637
>>
>> 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.

This looks like an oversight in the specification. We will discuss  
this on the next CCXML working group call and see if we can fix it in  
the candidate recommendation.

Best regards,

        RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C