Radhika and all,

sometimes, something more encompassing than a simple API might be helpful, particularly if we are talking about potentially distributed implementations of IP phones, supporting workstation GUI, etc. where not in all cases a strict client - server relationship can be identified (or persists for all time).

We are jointly working with others on the Mbus infrastructure that allows modularization of IP telephony/multimedia endpoints, gateways, gatekeepers/ proxies, etc. As a special case (one piece of the manyfold interactions that are possible), this allows to provide call control APIs based on simple (low overhead) message passing mechanisms (and, or course, can carry any API on top, such as Parlay). We are looking for further input on the particular subject of call and conference control and, in this context, are also looking at a model for describing and controlling capabilities and media channel attributes that seamlessly fits with the SDPng work undertaken in the IETF.

The Mbus (short for "Message Bus") provides a number of features for modular and robust system design including - automated detection of new system components; - may use host-local or link-local multicast (and thus inherently allows distribution of an endpoint across a LAN); - scalable mechanism for detecting component liveness; - tuple-based addressing for system-local unicast, multicast, broadcast; - simple message format with arbitrary payloads (easy to parse & implement); - extensible command sets (very small basic command set); - simple security mechanisms against eavesdropping on messages and spoofing; - supports client-server and peer-to-peer scenarios; - simple synchronization mechanisms; - provides a lightweight concept for policy mechanisms and voting (e.g. to determine permissions for placing a call or address resolution in parallel);

The basic Mbus stack implementations are available for reseach and evaluation purposes in C, C++, and Java from the Mbus web site.

In addition, various command sets have been and are being defined for the Mbus to allow for control of audio sources/sinks, RTP stacks, and call control. Further work is needed on the latter and on capability descriptions -- which is in progress.

Take a look at http://www.mbus.org/ for an outline of the work and the current Internet Drafts. Note that this is a work item of the MMUSIC WG of the IETF.

We would appreciate further input on this work.

Best regards, Joerg

Hi, Everyone:

In the last Q.13/16 Rapporteur meeting (August 21-25), we talked about the Parlay organization. The detail about Parlay can be found in the following URL:

http://www.parlay.org

It can be seen that it is an OPEN industry consortia for development of the APIs, and its call control API spec 2.1 seems to be the most advanced work that can support the call control applications like H.323, MEGACO/H.248, and others. The Parlay spec is written in UML, and recently CORBA IDL spec has also been produced.

The comments on the Parlay CC spec 2.1 are being sought for updating the spec across the industry. Many trials are also underway for the Parlay CC

API.

I am co-chairing the Parlay call control work group. If any company is interested to join the Parlay, they are welcome right away. The next Parlay meeting will be held on Sept 27-29, 2000 in Stockholm.

The efforts are under way to create one call control API spec across the industry: 3GPP N5, ETSI SPAN5, ITU-T, JAIN, and others. It is expected that representatives from all standard organizations will come to the next Parlay meeting (Sept 26-28) to discuss how a common CC API spec can be produced across the industry.

If you have any questions, please let me or others know.

Best regards,

Radhika R. Roy AT&T +1 732 420 1580 rrroy@att.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com