Parlay

Roy, Radhika R, ALCOO rrroy at ATT.COM
Tue Aug 29 11:24:09 EDT 2000


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 at tzi.uni-bremen.de]
Sent: Tuesday, August 29, 2000 10:17 AM
To: Roy, Radhika R, ALCOO; ITU-SG16 at mailbag.cps.intel.com
Cc: dku at tzi.uni-bremen.de; csp at 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

>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 at att.com
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv at mailbag.intel.com
>

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



More information about the sg16-avd mailing list