- sg16-avd - lists.packetizer.com

None
by Paul E. Jones 31 Aug '00

31 Aug '00

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

1 0

Re: response to open letter from Tom Taylor
by Tom-PT Taylor 30 Aug '00

30 Aug '00

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 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

1 0

Re: response to open letter from Tom Taylor
by Tom-PT Taylor 30 Aug '00

30 Aug '00

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: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 >

1 0

response to open letter from Tom Taylor
by Skran, Dale 30 Aug '00

30 Aug '00

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

1 0

Test - please ignore <eom>
by Patrick_Luthi＠PICTEL.COM 29 Aug '00

29 Aug '00

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

1 0

Re: [sip-h323] SIP-H.323 IWF protocol requirements
by Paul E. Jones 29 Aug '00

29 Aug '00

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 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

1 0

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Agboh, Charles 29 Aug '00

29 Aug '00

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)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

1 0

Re: Parlay
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

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: 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

1 0

Re: Parlay
by Joerg Ott 29 Aug '00

29 Aug '00

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

1 0

Parlay
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

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

1 0