Hi, Joerg: I will definitely refer the Mbus work to the Parlay community to have the close cooperation with IETF in addition to ITU-T's H.323/H.248 activities. I appreciate your efforts for referring the Mbus work in this respect. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Joerg Ott [mailto:jo@tzi.uni-bremen.de] Sent: Tuesday, August 29, 2000 10:17 AM To: Roy, Radhika R, ALCOO; ITU-SG16@mailbag.cps.intel.com Cc: dku@tzi.uni-bremen.de; csp@isi.edu Subject: Re: Parlay 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (1)
-
Roy, Radhika R, ALCOO