W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2004

Re: Questions about conference events

From: RJ Auburn <rj@voxeo.com>
Date: Fri, 24 Sep 2004 12:00:10 -0700
To: Werner Dittmann <Werner.Dittmann@t-online.de>, <www-voice@w3.org>
Message-ID: <BD79BCCA.1F06E%rj@voxeo.com>

Werner,

Thanks for the feedback on this. The items you listed below are indeed
issues in the current draft and the working group is right now finishing up
a new approach to the conference object that should solve the issues you
raised along with some issues that come up with large distributed
conferences. We are planning to probably remove the array that directly
references the connection objects and replace it with some more general info
such as counts of active connections and resource reservation details,
however the details are not finalized yet. We expect to publish this as a
updated release that we are looking to have public in late October.

I will add some detail to a few of your questions:

> - if both ids point to connections (both refer to objects in the
>   session.connections array) then it is a simple bridge between two
>   connections. No further handling necessary.

You are correct. 

> - if both ids point to a conference object? Is this allowed or
>   possible? If so - how to handle the connections of the conference
>   objects? Which conference object gets the connections? Or get both
>   the connections of the other?

Joining two conferences together should indeed be allowed. The merging of
the connection object should be that will be resolved in the spec update.

Thanks again for the feedback!

    RJ

On 09/15/2004 12:31, "Werner Dittmann" <Werner.Dittmann@t-online.de> wrote:

> 
> All,
> 
> during the implementation of a Java based CCXML interpreter I have some
> questions about the conference events. Maybe some CCXML specification
> guru can answer my questions and check my assumptions. Thanks.
> 
> 
> conference.created:
> 
> this event contains a reference to the conference object. This object
> contains the conference id and an array of the connections that belong
> to the conference. The <cerateconference> element does not provide any
> mechanisms to define connections that shall join the conference during
> the creation process. Is it therefore a safe assumption that the
> connections array of the conference object is empty when the
> interpreter receives this event?
> 
> conference.joined:
> 
> this event contains two ids. My assumptions to handle these ids are:
> 
> - if both ids point to connections (both refer to objects in the
>   session.connections array) then it is a simple bridge between two
>   connections. No further handling necessary.
> 
> - if one id (either id1 or id2) points to a conference object (refers
>   to an object in the session.conferences array) and the other id is a
>   connection then add the referenced connection object to the
>   connections array of the conference object. Additional question: how
>   to index the connections array of the conference object?
>   Sequentially from '0' to 'n' or is the connection id the index into
>   this connections array (similar to the session.connnections array)?
>   My assumption is to index it via the connection id. This would
>   simplify handling when dealing with a connection inside a
>   conference.
> 
> - if both ids point to a conference object? Is this allowed or
>   possible? If so - how to handle the connections of the conference
>   objects? Which conference object gets the connections? Or get both
>   the connections of the other?
> 
> conference.unjoined:
> 
> - similar assumptions as above (except for simple bridging - this is
>   handled via disconnect) only the opposite action.
> 
> Regards,
> Werner
> 
> PS: I've managed to open a Sourceforge project for this implementation.
> The projectname is CCXML4J.
> I just need some more testing, then I can put a first snapshot into the
> CVS repository. If all goes well this will be during the next weekend.
> 
> Werner
> 
> 

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800
Received on Friday, 24 September 2004 19:00:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:26 UTC