- sg16-avd - lists.packetizer.com

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

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

22 Jun '01

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.

1 0

!! Rates Are At Their Lowest! Refinance Now!
by Mark 22 Jun '01

22 Jun '01

Mortgage Rates have been slashed again! *Lower your monthly payment! *Shorten the term of your loan! *Reduce your interest rate! SAVE MONEY!!! NOW is the time to refinance... rates have NEVER been lower! We CAN assist everyone, even if you've been turned down before! Take just a minute to complete this form and a Loan Consultant will contact you at your convenience. http://www.mortgagelenderpower.com Your information is secure, confidential and you are under NO OBLIGATION for this free analysis. **************************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply to: mailto:orlando9524@yahoo.com?subject=remove ********************************************************** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Private telephone number in H.323v4
by Francois Audet 21 Jun '01

21 Jun '01

Of course... It's the sending side we need to clarify. > Oh, and on this particular case, surely receivers need to look in all > possible places, so it makes little difference where the > transmitter puts > this particular information! >

1 0

Re: Private telephone number in H.323v4
by Callaghan, Robert 21 Jun '01

21 Jun '01

Karl, I think that Francois's enhanced text will also help. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Klaghofer Karl ICN EN HC SE 81 Sent: Thursday, June 21, 2001 4:06 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: AW: Private telephone number in H.323v4 Francois, Paul, Bob and others, Please refer to section 6.1.2 of the most recent H.323 Implementers Guide (TD-031 PLEN) of the Brazil meeting. This IG section clarified previous inconsistencies in H.323 sections 7.8.2.1, 7.8.3.1 and 7.8.4.1 compared to H.225.0. I.e. the mentioned three H.323 sections have been updated for clarification on PNP number usage. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet: Mittwoch, 20. Juni 2001 01:27 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0