June 2001 - sg16-avd - lists.packetizer.com

Syntax method of GEF extension definition
by Pete Cordell 11 Jul '01

11 Jul '01

Hi All, As you may know, the most recent version of H.GEF.1 included a syntax based method of defining GEF extensions. I defined this so that people wouldn't get confused with trying to interpret a syntax based definition as pure ASN.1. My principle is, if you are defining something that is different to something that is already used, then make it obviously different. I'm fairly comfortable that the syntax is complete. Also, if people don't want to use that method of GEF definition they are not obliged to. I personally would therefore like to keep it in. However, we live in a democracy. Therefore, the person that gives me the highest bid can decide whether it stays or goes! Meanwhile, people can vote on whether it stays or goes by e-mailing me directly. I will then summarise and post the results to the list. In the event of a draw I'll keep it in. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Draft summary of 4th MoIP reliable transport conference call
by James_Renkel＠3COM.COM 30 Jun '01

30 Jun '01

The fourth in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, June 22, 2001. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. Once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, the requirements and possible evaluations are, if possible, to bepresented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. Some parties may present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Fred Lucas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. >From Brooktrout was: - Dave Duehren. The call began by discussing the proposed summary of the third conference call. Cisco asked that the "background paragraph" from the first conference call summary be added to this and all future conference call summaries. With that addition, the meeting summary was agreed to and approved. After making that addition, Jim will send the meeting summary to relevant e-mail reflectors. Next, it was agreed that draft conference call summarries would be sent immediately to the e-mail reflectors, then reviewed, ammended if necessary, and approved at the next conference call. That procedure is to start with the summary of this conference call [which is this e-mail.]. Then, the next two conference calls were scheduled, as follows: - Friday, 06/29/2001, 10:30 A.M., CDT - Friday, 07/06/2001, 10:30 A.M., CDT The dial-in arrangements for the conference calls would be the same as for this conference call: access number +1.847.262.0999; conference ID "06647" (That's "0MOIP" (zero-em-oh-eye-pea) on your touch-tome keypad.). [If you plan to participate in these conference calls, please inform Jim Renkel ASAP at James_Renkel(a)3Com.com so that sufficient conference bridge ports can be arranged.] Next, the CommWorks proposed language for media stream / protocol stack switching was discussed. It was agreed that, while interesting in general and perhaps impacting the reliable transport protocol, this really is material for annexes to V.moip and relevant signaling channel protocol specifications. Then, the meeting returned to Table 1 of CommWork's PCM01-020 contribution to the Nice, FR, rapporteur's meeting. It was agreed that the forward error correction characteristic should, at most, be an optional capability of the reliable transport protocol and that its use must be negotiated on a session-by-session basis. It was then agreed that forward error correction was but a means, perhaps with other characteristics or requirements, to the end of low latency. It was agreed that low latency, however achieved, was a desirable characteristic of the reliable transport mechanism. Mehryar will draft requirement language to this effect. In this vein, it was then agreed, in considering requirements for a reliable transport protocol, to concentrate first on "high-level" requirements or basic capabilities, such as low latency, and then on "low-level" requirements or enhancements, such as forward error correction. When that consideration is complete, all requirements would be prioritized in some way TBD. It was agreed that forward error correction and error correction by continuous transmission should be relegated to the low-level or enhancements category. Agreement could NOT be reached on whether error correction by retransmission should also be relegated, or be placed in the high-level or basic capabilities category. Finally, it was agreed that rather than continue enumerating capabilities, characteristics, requirements, etc., we would next consider deficiencies, if any, in known protocols that would prevent them from being used for MoIP and FoIP, or make their use less than ideal. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

How "mandatory" is the presence of G.711 in the Terminal Capability set
by Frank Derks 29 Jun '01

29 Jun '01

6.2.5/H.323 states that all terminals must be _capable_ to encode and decode G.711 A-law and u-law. 6.2.5.3 states that an endpoint need not indicate this support if it knows that it will be communicating on a low bit-rate segment. This seems somewhat contradictory. However, the fact that G.711 must be supported does not really mean that support should also be indicated in the capability set. This would be in line with the statement in 6.2.5.3. The question therefore remains, must G.711 support always be indicated in the capability set if the endpoint has no knowledge about the properties of the network that it will be communicating on? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Megaco/H.248
by suryapratap vamsi 28 Jun '01

28 Jun '01

Hello List, Megaco and H.248 are two different protocols ? or they are same ? I am assuming they are same, If they are different please advice. Thanks Suryavamsi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

asn1 out of standards ?
by Michael Stini 28 Jun '01

28 Jun '01

Hi, I hope that I am addressing the correct mailing list. Where can I get the asn1 definitions related to the several Hxyz standards. Do I have to copy them out of the standard, or are there files / documents dedicated to the asn1 definitions? thank you very much, michael stini ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Summary of 3rd MoIP reliable transport conference call
by James_Renkel＠3COM.COM 27 Jun '01

27 Jun '01

The third in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, June 22, 2001, between representatives of The CommWorks Corp. and Cisco Systems. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. It is understood that there is a desire, once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, to have the requirements and possible evaluations presented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. It is also understood that some parties plan to present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the proposed summary of the first conference call. Cisco asked that the following sentence be added at the end of the 4th paragraph (Which begins "The call began by discussing ...."): It is also understood that some parties plan to present a draft protocol proposal to that meeting. With that addition, the meeting summary was agreed to and approved. After making that addition, Jim will send the meeting summary to relevant e-mail reflectors. Next, the proposed summary of the second conference call was reveiwed and approved as proposed. Jim will also send that summary to relevant e-mail reflectors. Next, the CommWorks proposed language for media stream / protocol stack switching was discussed. The definitions and first proposed agreement were tentatively accepted as proposed. There was much discussion of the second proposed agreement, and Jim will redraft it. Also, these proposals will be copied into a Word document so that changes can be tracked. Next, the meeting returned to Table 1 of CommWork's PCM01-020 contribution to the Nice, FR, rapporteur's meeting. It was agreed to split the "reliable" characteristic into "error detection" and "error correction" requirements. It was also agreed that "non-erasing" and "non-duplicating" were requirements for the reliable transport protocol to be used with MoIP. Jim will draft language stating these requirements. Finally, the next conference call was scheduled for Tuesday, 6/26/2001, 10:30 A.M., CDT, 8:30 A.M. PDT, with the same arrangements as this conference call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Summary of MoIP reliable transport conference call
by James_Renkel＠3COM.COM 25 Jun '01

25 Jun '01

For those of you that don't have Visio 2000, here is the diagram that was attached to the first conference call summary converted to a .GIF: (See attached file: Reliable transport.gif) Sorry for any inconvenience. Jim Adrian Zakrzewski <azakrzewski(a)telogy.com> on 06/25/2001 09:48:31 AM Please respond to Adrian Zakrzewski <azakrzewski(a)telogy.com> Sent by: Adrian Zakrzewski <azakrzewski(a)telogy.com> To: tr301(a)tiacomm.org cc: (James Renkel/MW/US/3Com) Subject: RE: Summary of MoIP reliable transport conference call Although I knew the type of application I still couldn't open it :(((( The file was created by a newer version of Vision (I have ver. 5.0). James, could you possibly resend the drawing in some non-Microsoft format like .jpg or .bmp or even paste it into a word document. regards, Adrian > -----Original Message----- > From: Michael.McLaughlin(a)lakecommunications.com > [mailto:Michael.McLaughlin@lakecommunications.com] > Sent: Monday, June 25, 2001 6:57 AM > To: tr301(a)tiacomm.org > Cc: tr301(a)tiacomm.org > Subject: Re: Summary of MoIP reliable transport conference call > > > > > > Neither I nor my PC know what type of application is used to > open a VSD > file. > Could you convert it to a Word file for me ? > > Michael. > > > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster(a)lakecommunications.com > > This footnote also confirms that this email message has been swept > by MIMEsweeper for the presence of computer viruses. > > www.lakecommunications.com > ********************************************************************** >

1 0

FW: [OpenH323]Fast Connect & H245 tunneling: do they really work?
by Agboh, Charles 24 Jun '01

24 Jun '01

-----Original Message----- From: Alain Daigle [mailto:daiglea@memotec.com] Sent: Tuesday, June 19, 2001 3:14 PM To: openh323(a)openh323.org Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work? Hi, H.323v2 seems to indicate that with faststart, the opening of a H245 channel is optional. Like in the following sections: 8.1.7.2 Switching to H.245 Procedures After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. 8.2.3 Switching to a Separate H.245 Connection When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. And in the H323 implementation guide (from packetizer), there is a section on how a fastconnect call with no h245 channel should be terminated. Call Termination 2a. The following is how a call shall be terminated if the control channel is not open (Fast Connect was used and no control channel was ever established) but the call-signaling channel is open. Note that, in this case, only the initiating side is required to send ReleaseComplete. I assume that it is an oversight that the two cases are not consistent. I also assume that the remote EP will close the call-signaling channel upon receipt of ReleaseComplete and consider the call terminated. But if the remote is asking for a h245 channel (separate or tunneled) after the call is established, it's mandatory to support that... Alain Daigle ----- Original Message ----- From: "Chris Wayman Purvis" <chriswaymanpurvis(a)hotmail.com> To: <openh323(a)openh323.org> Sent: Tuesday, June 19, 2001 5:11 AM Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work? Nicola, >(2). We partially overcame the problem modifying the Openh323 GK in order >to >force h245Tunneling = TRUE in any case. Everything seems to be working >fine, >with both H.245 Tunnelling capable terminals (e.g. openphone) and H.245 >Tunneling non-capable terminals (e.g. Netmeeting). Now, we hoped to >experience some call setups based on the Fast Connect only, but even the >supposed Fast Connect capable terminals (e.g. ohphone & openphone) try to >perform a (tunneled) H.245 negotiation... even if some capabilieties seems >to be agreed by using the fastStart field... >==>Did anyone experience a TRUE Fast Connect setup (with no additional >FACILITY messages for H.245 tunneling)? With which terminals? If you find a device that does no H.245 negotiation at all, that device is not compliant with H.323. FastStart is a hack to get media flowing as soon as possible; it is not a substitute for H.245. Regards, Chris _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------ ------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Summary of MoIP reliable transport conference call
by David Duehren 22 Jun '01

22 Jun '01

Why do we get this after the "next conference call" is scheduled. Some of would like to participate. David Duehren Vice President of R&D, CTO dwd(a)brooktrout.com <mailto:dwd@brooktrout.com> Brooktrout, Inc. 410 First Avenue Needham, MA 02494 U.S.A. Tel: +1-781-433-9402 / Fax: +1-781-433-9202 > -----Original Message----- > From: James_Renkel(a)3com.com [mailto:James_Renkel@3com.com] > Sent: Friday, June 22, 2001 2:36 PM > To: itu-sg16(a)mailbag.cps.intel.com; tr301(a)tiacomm.org; > tsg16q11(a)itu.int > Subject: Summary of MoIP reliable transport conference call > > > > > A conference call was held on Friday, June 15, 2001, between > representatives of The CommWorks Corp. and Cisco Systems to begin > discussing the requirements for a reliable transport protocol > to be used > with MoIP, the evaluations of existing protocols against > those requirements, > and the eventual recommendation of an exisitng (possibly > modified) or new > protocol for that purpose. > > On the call from The CommWorks Corp. were: > - Mike Nicholas; and > - Jim Renkel. > > From Cisco Systems were: > - Herb Wildfeuer; and > - Mehryar Garakani. > > The call began by discussing the events that led up to the > call. It was > agreed that the goal of this and future follow-on calls is to > develop a > joint CommWorks / Cisco Systems contribution to the next meeting of > TR-30.1 giving requirements for the MoIP reliable transport mechanism > that could be agreed to by the two companies, and possibly an > evaluation > of existing protocols against these requirements that both > companies could > also agree to. Requirements and evaluations that could not be > agreed to by > the two companies would be left for presentation by each > company separately. > It is understood that there is a desire, once the > requirements and possible > evaluations have been presented to TIA TR-30.1 and agreed to > by them, to have > the requirements and possible evaluations presented to the > IETF 51 meeting > in London, UK, during the week of 8/5/2001. It is also > understood that some > parties plan to present a draft protocol proposal to that meeting. > > It was then agreed that proprietary information previously > disclosed in > contributions to the ITU-T and TIA groups studying MoIP could > be discussed > in these conference calls, but no new proprietary information > should be > first disclosed in these calls. > > It was then suggested and agreed that a small "reference > model" would be > useful in the discussions. The following was agreed to as the > refence model, > subject to future modification as may be necessary: > - The reliable transport issue is bi-directional and > symmetric, but is > perhaps best addressed by: considering the > uni-directional, asymetric > case; then combining the uni-directional case with a > mirror image of > itself to yield the bi-directional case. > - The uni-directional case can be represented by this diagram: > (See attached file: Reliable transport.vsd). > > Discussion then turned to CommWork's contribution PCM01-020, > "Transport > mechanisms in MoIP operations", to the Nice, FR, rapporteur's > meeting of > Q11/16, in particular a row by row discussion of Table 1, "Transport > mechanism characteristics", on page 8 of that contribution. > > It was agreed that the transport protocol must support > two-way, unicast > sessions. It need not support one-way only or multicast > sessions. Jim Renkel > will draft requriements statements reflecting this for > consideration for > inclusion in the joint contribution . > > It was agreed that the protocol should be structure > preserving, but that > this should be described as "packet oriented rather than > stream oriented." > Mehryar Garakani will draft requirements statements > reflecting this for > consideration for inclusion in the joint contribution . > > In considering the next characteristic, "Structure format > discriminating", > it was agreed that the issue really being considered here is that of > switching / transitioning among VoIP, FoIP, and MoIP "modes" > during the > course of a call. While no firm agreement was reached on the > requirements > and mechansim for doing this, the discussion seemed to > indicate that the > companies were close to agreement. Each company will draft > requirements > for this to be exchanged via e-mail prior to and discussed at the next > conference call. > > The next conference call is to be held Tuesday, 6/19/2001, at > 10:30 A.M., > CDT, 8:30 A.M., PDT. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Summary of 2nd MoIP reliable transport conference call
by James_Renkel＠3COM.COM 22 Jun '01

22 Jun '01

Another conference call was held on Tuesday, June 19, 2001, between representatives of The CommWorks Corp. and Cisco Systems to continue discussing a reliable transport protocol to be used with MoIP. On the call from The CommWorks Corp. were: - Mike Nicholas; - Fred Lucas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the e-mail summary of the previous conference call. As Cisco had just received the summary from CommWorks, they asked for additional time to review it. It was agreed that when conference call summaries were agreed to by all parties, they would be sent to the MoIP e-mail reflectors. Other working e-mails, however, would NOT be sent as is to the MoIP e-mail reflectors, but held until work had progressed to, e.g., a draft joint contribution. That would then be sent to the MoIP e-mail reflectors. Next, additional transport mechanism characteristics from PCM01-020 were considered. It was agreed that the non-corrupting, and order-preserving / sequenced characteristics were desirable for MoIP. Additionally, a characteristic not identified in PCM01-020, namely support for expedited and non-expedited data transfer, was identified and agreed to. Jim will draft requirement language for the non-corrupting characteristic, and Mehryar will draft requirement language for the sequenced and expedited characteristics. The remainder of the meeting was spent discussing media-stream(s) and protocol stack switching. Cisco did not yet have proposed language for this, so CommWork's proposed language was discussed. Several changes and additions to this were tentatively agreed to, and Jim will revise CommWork's proposal for the next conference call. The next conference call was scheduled for Friday, 6/22/2001, 10:30 A.M., CDT, 8:30 A.M. PDT, with the same arrangements as this conference call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0