Orit, Bob, and Others,
I have attached the modified H.323 URL specification for review, which hopefully includes all of the comments from the meeting.
Please let me know if you see any errors or find things that you want to change.
Thanks,
Paul
This has gone far enough, and I'm sorry if the whole matter is due to a
misunderstanding. My previous note explained my precise point of
sensitivity in your remarks, but it has occurred to me that you may simply
have been trying to make the reference clear.
Apparently I've left the impression that Nortel is trying to get rid of you.
Definitely not! We recognize the valuable job you are doing. All I ask is
a certain amount of care (when you speak as chair) that you not name
individual ITU-T …
[View More]members in an unfavourable context (whether it's saying
that IETF participants cannot be trusted or naming Nortel Networks as the
contributor of a non-SG 16 document you proceed to criticize).
Tom Taylor
[View Less]
What I found most irregular was your specific attribution of the document in
question to Nortel Networks. It is not that we are ashamed of the document,
but that your naming of Nortel Networks in the process of your commentary
seemed calculated to affect the attitude of other parties present in Q.13/16
toward Nortel. I have not observed such behaviour in other delegates, and
believe that it is incompatible with a chairman's role.
> -----Original Message-----
> From: Skran, Dale [mailto:…
[View More]DSkran@SONUSNET.COM]
> Sent: Wednesday, August 30, 2000 9:30 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: response to open letter from Tom Taylor
>
>
> Dear Tom:
> Allow me to repeat the comments I made during the meeting. I
> noted that a
> large contribution comparing SIP and H.323 had been submitted to 3GPP,
> having the conclusion of SIP's superiority. I complained that I was
> disappointed in the non-technical nature of much of the
> material provided,
> and urged the delegates to bring in real technical
> contributions concerning
> the possible demerits of H.323, with a view to the
> improvement thereof. My
> goal, then, as now, is the improvement of H.323, and also to call the
> delegates attention to a document whose existance they may
> not have been
> aware of, and which might stimulate them to bring in additional
> contributions.
> Any implication that, for example, 3GPP members are gullible,
> or there were
> no other contributions in 3GPP on this topic appears to be
> speculation. In
> addition, the idea that I or Sonus might profit in some
> fashion from these
> comments is both speculative and humorous. As you can
> clearly see, they
> have brought me nothing but trouble so far. I am still
> hoping for the real
> gain of additional valuable H.323 related contributions.
> I would like to take this opportunity to thank Francois Audet
> for his many
> contributions to H.323 over the years, both as an editor and as a
> contributor, and also to his many contributions to the ATM
> Forum. Francois
> has been, without fail, a positive and helpful member of Q13
> and the H.323
> community, and I would like to thank Nortel for supporting
> his standards
> work.
> One of the criticisms of H.323 in the 3GPP discussions
> appeared to be the
> idea that SIP would be easier to modify for the wireless
> environment than
> H.323, apparently because of a perception that the SIP
> community is more
> open to change. I feel this is completely unfair and untrue. As
> rapporteur, I have always welcomed new contributors and new
> ideas into the
> H.323 system of recommendations, and would like to urge the further
> consideration of H.323 for wireless/mobile applications by
> groups other than
> 3GPP (of course, further consideration by 3GPP is also
> welcome!). Such
> groups will find Q13/WP2/SG16 ready and eager to work with
> them in defining
> any changes needed for the wireless/mobile environment.
> I would also like to call attention to the continuing work of
> Q13 in H.323
> Annex H and I.
> H.323 Annex H (User Service, and Terminal Mobility in H.323)
> Determination 11/00 Editor J. Sundquist (Nokia)
> H.323 Annex I (Packet based MM Telephony over Error Prone Channels)
> Determination 11/00 Editor B. Aronson (Toshiba)
>
> Sincrely,
> Dale Skran
> Q13 Rapporteur
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
Dear Tom:
Allow me to repeat the comments I made during the meeting. I noted that a
large contribution comparing SIP and H.323 had been submitted to 3GPP,
having the conclusion of SIP's superiority. I complained that I was
disappointed in the non-technical nature of much of the material provided,
and urged the delegates to bring in real technical contributions concerning
the possible demerits of H.323, with a view to the improvement thereof. My
goal, then, as now, is the improvement of H.323,…
[View More] and also to call the
delegates attention to a document whose existance they may not have been
aware of, and which might stimulate them to bring in additional
contributions.
Any implication that, for example, 3GPP members are gullible, or there were
no other contributions in 3GPP on this topic appears to be speculation. In
addition, the idea that I or Sonus might profit in some fashion from these
comments is both speculative and humorous. As you can clearly see, they
have brought me nothing but trouble so far. I am still hoping for the real
gain of additional valuable H.323 related contributions.
I would like to take this opportunity to thank Francois Audet for his many
contributions to H.323 over the years, both as an editor and as a
contributor, and also to his many contributions to the ATM Forum. Francois
has been, without fail, a positive and helpful member of Q13 and the H.323
community, and I would like to thank Nortel for supporting his standards
work.
One of the criticisms of H.323 in the 3GPP discussions appeared to be the
idea that SIP would be easier to modify for the wireless environment than
H.323, apparently because of a perception that the SIP community is more
open to change. I feel this is completely unfair and untrue. As
rapporteur, I have always welcomed new contributors and new ideas into the
H.323 system of recommendations, and would like to urge the further
consideration of H.323 for wireless/mobile applications by groups other than
3GPP (of course, further consideration by 3GPP is also welcome!). Such
groups will find Q13/WP2/SG16 ready and eager to work with them in defining
any changes needed for the wireless/mobile environment.
I would also like to call attention to the continuing work of Q13 in H.323
Annex H and I.
H.323 Annex H (User Service, and Terminal Mobility in H.323)
Determination 11/00 Editor J. Sundquist (Nokia)
H.323 Annex I (Packet based MM Telephony over Error Prone Channels)
Determination 11/00 Editor B. Aronson (Toshiba)
Sincrely,
Dale Skran
Q13 Rapporteur
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
Jean-Francois,
Here are a few benefits for using v3:
H.323v3 introduces new fields to allow the GK to signal whether Annex E
should be used or not. For build large-scale devices, Annex E is definitely
worth considering. (Annex E was written for V2, but related RAS fields were
added in v3.)
It is possible to use the same TCP connection for multiple calls.
Text was added to explain the use of Lightweight RRQs (this may have been in
the IG, but I can't recall). A number of things are better …
[View More]explained,
revisions have been made via the IG that may result in interworking issues
if the latest texts (including the IG are not followed). Indeed, things
should be backward compatible, but the clarifications are important, as they
were obviously points of confusion.
Version 4 has even more. Here's a few:
* Gateway decomposition section
* Support for new services and features
* Annex L, Annex K, H.450.x, etc.
* Generic Extensibility Framework
* Additive Registrations
* Alternate Gatekeeper usage fully defined
* Usage Information Reporting
* Endpoint Capacity Reporting
* Desired protocol indication
* Reporting call status with multiple IRRs
* Call Linkage
* Early H.245
* Support for pre-paid calling cards
You can definitely see some advantages to v4. Probably the most important
introduction in V4 is the Generic Extensibility Framework. With that, we
can now add new features to the H.323 protocol specification that the
signaling entities in the middle of the call can remain completely ignorant
about. This allows us to add new features that work end to end without
forcing the intermediate equipment to be updated-- that's one very good
reason for moving to v4. It's quite possible that v4 may serve as the
minimum specification for some time to come.
Of course, this was possible before with "non-standard" mechanisms, but it
is hoped that the GEF will introduce fewer ripples in the H.323
standardization effort and the software development cycle.
This extensibility framework may also serve well for feature interaction
between SIP and H.323. I realize that feature interaction is not an
immediate goal, but it's nice to have the foundation in place to try to
utilize it.
That's why I suggested at the meeting to go with the latest: v4. It's true
that the differences between v2 and v3 are small, but a few scalability
issues were addressed. Since signaling interworking is not a major CPU
consumer, I would think you'd want to take every possible step to increase
the number of calls handled on a single box. That could easily go over the
number of sockets the box can support. So using Annex E or carrying
multiple calls over a call signaling channel is desirable.
Of course, I realize that NetMeeting does not support these features, but I
think that heavier consideration should be given to other H.323 entities. I
cannot recommend trying to offer residential phone service using H.323v2
where SIP interworking is required: it's not nearly as scalable as v3 since
SIP interworking forces all calls to be directed to one box or a few boxes.
SIP works well there, but one really needs Annex E/H.323 to get comparable
scaling ability from H.323.
Paul
----- Original Message -----
From: "Jean-Francois Mule" <jfmule(a)clarent.com>
To: <paulej(a)packetizer.com>
Cc: "Wang, Dave" <dwang(a)nuera.com>; "aHit! IMTC (E-mail)" <ahitag(a)imtc.org>
Sent: Tuesday, August 29, 2000 12:53 PM
Subject: RE: [sip-h323] SIP-H.323 IWF protocol requirements
> Paul,
> Based on the current aHit IWF requirements, could help the group identify
> what particular h323v3 functionality would be mandatory for the IWF.
> If we can meet the requirements with v2, then we should mandate v2 which
> means also that v3 implementations will meet the requirements since there
is
> some backward compatibility.
>
> Jean-Francois Mule
> Clarent Corp.
>
> > -----Original Message-----
> > From: Wang, Dave [mailto:dwang@nuera.com]
> > Sent: Tuesday, August 29, 2000 8:59 AM
> > To: aHit! IMTC (E-mail)
> > Subject: FW: [sip-h323] SIP-H.323 interworking Requirements Draft
> >
> >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > > Sent: Monday, August 28, 2000 11:53 PM
> > > To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com;
> > > ITU-SG16(a)mailbag.cps.intel.com
> > > Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft
> > >
> > >
> > > Radhika,
> > >
> > > A few months ago, I published the final set of ASN.1
> > > corrections for H.323v3
> > > to the ITU-T SG16 mailing list and to the IMTC H.323 mailing
> > > list. I also
> > > contact 11 companies that have H.323v3 products or products
> > > in development
> > > that I was aware of.
> > >
> > > There are certainly plenty of v3 implementations in
> > progress and it's
> > > important to be prepared for those implementations. H.323v4 will be
> > > approved in November and I expect even quicker adoption of that
> > > Recommendation, because it introduces a lot of new functionality.
> > >
> > > I think what the group should try to strive for is a
> > > specification that will
> > > work with the most recent version of H.323-- H.323v4. Of
> > > course there will
> > > be few implementations, but there are not a large number of
> > > new mandatory
> > > features. (I don't have a list handy.)
> > >
> > > For a "bigger picture" view of what's new in the various
> > > versions of H.323,
> > > see:
> > > http://www.packetizer.com/iptel/h323/
> > >
> > > Best Regards,
> > > Paul
> > >
> > > ----- Original Message -----
> > > From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>
> > > To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com>
> > > Sent: Monday, August 28, 2000 10:32 PM
> > > Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft
> > >
> > >
> > > > Hi, Everyone:
> > > >
> > > > Here is my view as stated below:
> > > >
> > > > It is very difficult to find any vendor to support H.323
> > > version 3. Many
> > > > companies are now testing vendor implementations of H.323
> > > version 2, and
> > > it
> > > > is also reported that multivendor interoperability at the
> > > version 2 level
> > > is
> > > > still problematic. In many cases, no promise has been
> > > obtained from the
> > > > major vendors when they will support version 3. It may be
> > > very nice to
> > > have
> > > > SIP/H.323 v3 interworking, but we think SIP/H.323 v2
> > > interworking should
> > > > come first.
> > > >
> > > > Considering all factors, I think that we should keep our first
> > > interworking
> > > > requirements to support H.323 version 2 as defined in the
> > > present draft
> > > > (while we may consider for H.323 version 3 in the future).
> > > >
> > > > So, I recommend that we should make any changes in the
> > > present draft.
> > > >
> > > > Best regards,
> > > > Radhika R. Roy
> > > > AT&T
> > > > +11 732 420 1580
> > > >
> > > > -----Original Message-----
> > > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
> > > > Sent: Sunday, August 27, 2000 10:32 PM
> > > > To: sip-h323(a)egroups.com
> > > > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft
> > > >
> > > >
> > > > Hi, Everyone:
> > > >
> > > > I have just returned from the ITU-T SG16 Q.13 (H.323)
> > > meeting where our
> > > > SIP-H.323 Interworking requirement draft was also discussed.
> > > >
> > > > The Q.13 members have strongly recommended that we should
> > > consider H.323
> > > > version 3 (instead of version 2) for our SIP-H.323
> > > interworking work.
> > > >
> > > > We would appreciate if you would kindly provide your
> > comments on the
> > > point.
> > > >
> > > > Best regards,
> > > > Radhika R. Roy
> > > > AT&T
> > > > +1 732 420 1580
> > > > rrroy(a)att.com
> > > >
> > > >
> > > > To Post a message, send it to: sip-h323(a)eGroups.com
> > > >
> > > > To Unsubscribe, send a blank message to:
> > > sip-h323-unsubscribe(a)eGroups.com
> > > >
> > > >
> > > > To Post a message, send it to: sip-h323(a)eGroups.com
> > > >
> > > > To Unsubscribe, send a blank message to:
> > > sip-h323-unsubscribe(a)eGroups.com
> > > >
> > > >
> > > > To Post a message, send it to: sip-h323(a)eGroups.com
> > > >
> > > > To Unsubscribe, send a blank message to:
> > > sip-h323-unsubscribe(a)eGroups.com
> > > >
> > >
> > > -------------------------- eGroups Sponsor
> > > -------------------------~-~>
> > > Need EDA tools on a short term or peak load basis?
> > > Take a free 7 day trial!
> > > http://click.egroups.com/1/8464/7/_/302437/_/967548702/
> > > --------------------------------------------------------------
> > > -------_->
> > >
> > > To Post a message, send it to: sip-h323(a)eGroups.com
> > >
> > > To Unsubscribe, send a blank message to:
> > > sip-h323-unsubscribe(a)eGroups.com
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
hi all,
perhaps we can procede as we planned with H.323v2 and add H.323v3 features
as an extension package of some sort.
regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Tuesday, August 29, 2000 4:43 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: FW: [sip-h323] SIP-H.323 interworking Requirements Draft
FYI
-----Original Message-----
From: Roy, Radhika R, ALCOO
Sent: Monday, August 28, 2000 10:41 PM
To: 'sip-h323(a)egroups.com'; sip-h323(a)…
[View More]egroups.com
Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft
Hi, Henning:
I agree with you (please also see my response provided below).
Best regards,
Radhika R. Roy
-----Original Message-----
From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
Sent: Monday, August 28, 2000 12:12 PM
To: sip-h323(a)egroups.com
Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft
"Roy, Radhika R, ALCOO" wrote:
>
> Hi, Everyone:
>
> I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our
> SIP-H.323 Interworking requirement draft was also discussed.
>
> The Q.13 members have strongly recommended that we should consider H.323
> version 3 (instead of version 2) for our SIP-H.323 interworking work.
What practical difference does it make? Could you summarize the relevant
differences?
Presumably, a v3 terminal is going to interoperate with v2 terminals.
For the next year, at the very least, the only real implementation to
worry about is NetMeeting (v2, I assume).
-----Original Message-----
From: Roy, Radhika R, ALCOO
Sent: Monday, August 28, 2000 10:32 PM
To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com
Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft
Hi, Everyone:
Here is my view as stated below:
It is very difficult to find any vendor to support H.323 version 3. Many
companies are now testing vendor implementations of H.323 version 2, and it
is also reported that multivendor interoperability at the version 2 level is
still problematic. In many cases, no promise has been obtained from the
major vendors when they will support version 3. It may be very nice to have
SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should
come first.
Considering all factors, I think that we should keep our first interworking
requirements to support H.323 version 2 as defined in the present draft
(while we may consider for H.323 version 3 in the future).
So, I recommend that we should make any changes in the present draft.
Best regards,
Radhika R. Roy
AT&T
+11 732 420 1580
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com]
Sent: Sunday, August 27, 2000 10:32 PM
To: sip-h323(a)egroups.com
Subject: [sip-h323] SIP-H.323 interworking Requirements Draft
Hi, Everyone:
I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our
SIP-H.323 Interworking requirement draft was also discussed.
The Q.13 members have strongly recommended that we should consider H.323
version 3 (instead of version 2) for our SIP-H.323 interworking work.
We would appreciate if you would kindly provide your comments on the point.
Best regards,
Radhika R. Roy
AT&T
+1 732 420 1580
rrroy(a)att.com
To Post a message, send it to: sip-h323(a)eGroups.com
To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
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(a)mailbag.cps.intel.com
Cc: dku(a)tzi.uni-bremen.de; csp(a)isi.edu
Subject: …
[View More]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(a)att.com
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv(a)mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
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 …
[View More]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(a)att.com
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv(a)mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
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
…
[View More]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(a)att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
