July 2000 - sg16-avd - lists.packetizer.com

Re: Voice Signal Level in H323 Terminal/Gateway
by Callaghan, Robert 05 Jul '00

05 Jul '00

I think that TIA TR41 and ETSI TIPHON are working on voice quality for VoIP. This work should be reference or copied. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Sakae OKUBO [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Monday, July 03, 2000 10:10 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Voice Signal Level in H323 Terminal/Gateway At 14:14 -0400 00/06/30, Shan Lu wrote: >I'd like to start a discussion on how to set speech signal level in an >H323 environment. For the H.320 system, a similar situation arose. After the initial version of H.320 had been approved in December 1990, audio level setting problem was raised and specifications were added in the March 1996 revision as section 4.2.1 referring to P-series Recommendations. For your convenience an excerpt is attached at the end of this message. I hope this is also applicable to the H.323 system or becomes at least a good starting point. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Excerpt from H.320 (this has been converted to text from Word file) 4 Terminal requirements 4.1 Environments Under study. 4.2 Audio and video arrangements 4.2.1 Audio arrangements A terminal can have one or more of three different arrangements: - handset function; - handsfree function for a small group of users (up to three users); - handsfree function for more than three users (conference terminal). The audio characteristics are defined for each of these functions. Furthermore, the bandwidth of the transmitted speech is taken into consideration. The principles used are identical with those for telephony terminals. That is, the sensitivity for handset function and handsfree function designed for personal use or for a small group of users is specified in loudness ratings, and the sensitivity for conference terminals is specified as output levels. 4.2.1.1 Test principles 4.2.1.1.1 Handset function The sensitivity measurement of a terminal when a handset is used shall be based on the principles described in Recommendation P.64. The loudness rating shall be calculated as described in Recommendation P.79. 4.2.1.1.2 Handsfree function for a small group of users The sensitivity measurement of the handsfree function of a terminal designed for a small group of users shall be based on the principles described in Recommendation P.34. The applied test signal level at the digital input when measuring receive sensitivity shall be -30 dBm0. The user position for a visual telephone terminal depends on the design of the terminal. The real user position as recommended by the supplier might be different compared with the position used for measurements. A correction factor shall be used. The correction factor is: F(dB) = 20 log10 {Ds/D0} where Ds is the distance between the recommended user position and the terminal and D0 is the reference distance of 50 cm. The loudness rating shall be calculated as described in Recommendation P.79. 4.2.1.1.3 Handsfree function for a conference terminal The principles described in Recommendation P.30 shall be used. 4.2.1.2 Sensitivity 4.2.1.2.1 General For handset terminals and handsfree terminals designed for a small group of users, the sensitivity shall be specified as loudness ratings: Send Loudness Rating (SLR) and Receive Loudness Rating (RLR). The definitions of SLR and RLR are found in Recommendation P.10. For conference terminals, the sensitivity shall be specified in terms of input and output levels. 4.2.1.2.2 Receive volume control For handsfree and loudspeaking terminals, a volume control shall be provided. Where a manual receive volume control is provided, the minimum control range shall be to -15 dB from the test position. Where an automatic receive volume control is provided, the RLR value obtained with a line level of -15 dBm0 shall not exceed that RLR value which is obtained with a line level of -30 dBm0 by more than 15 dB. 4.2.1.2.3 Handset function The requirements of Table 4 shall be met. Table 4/H.320 - Sensitivity of the handset function 3.1 kHz bandwidth(Note) 7 kHz bandwidth SLR 8 8 RLR 2 7 NOTE - 3.1 kHz bandwidth includes both G.711 and G.728 coding. The manufacturing tolerances are +/-3 dB. 4.2.1.2.4 Handsfree function The requirements of Table 5 shall be met. Table 5/H.320 - Sensitivity of the handsfree function 3.1 kHz bandwidth(Note) 7 kHz bandwidth SLR 13 - F 13 - F RLR -7 - F -5 - F NOTE - 3.1 kHz bandwidth includes both G.711 and G.728 coding. The receive RLR requirement shall be met when the receive volume control is in its maximum position. The manufacturing tolerances are +/- 4 dB. 4.2.1.2.5 Conference terminals The procedures and values specified in Recommendation P.30 shall be used. 4.2.2 Video arrangements Under study. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Intellectual property/patents on H.323 Annex K???
by Frank Derks 05 Jul '00

05 Jul '00

H.323 Annex K/APC-1811 (May 2000 meeting), states that the ITU has "...received notice of intellectual property, protected by patents, which may be required to implement this recommendation". Is anyone in a position to inform me which patent(s) are involved? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Comments on H.225v4 and H.323v4
by Klaghofer Karl ICN EN HC SE 81 05 Jul '00

05 Jul '00

The term "Package" is already used by H.248. I do not like the term "Generic Feature". "Generic Parameter" was a good and appropriate name - I propose to keep it as proposed by Paul in the current v4 draft. Karl > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Gesendet am: Tuesday, July 04, 2000 20:23 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: Comments on H.225v4 and H.323v4 > > Morgan, > > > H.323 /p75: The change of name from 'package' to 'parameter' is > > inappropriate. > > If the name has to be changed from 'package', it should be changed to > > genericFeature. > > I proposed this change, because the word "package" conflicted with H.248 > "packages" and I thought that it was too confusing. GenericParameter > seemed > like a reasonable name. I don't like the idea of calling it a "generic > feature", because the structures in themselves are not "features". One > uses > the "generic parameter" structures in order to implement "features". > > How about "generic fields" or "generic elements"? I still prefer "generic > parameter" over those. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

several gatekeepers
by Wolfgang Bandow 04 Jul '00

04 Jul '00

Hello H.323-Experts, in connection with H.323 based IP-telephony in a PISN environment we came across the question whether it is permitted to have more than two Gatekeepers involved in a point to point H.323 connection. Is this in line with H.323 conventions? >From my point of view this situation also occurs in case of a call transfer, if the endpoints are located in different zones and the gatekeeper routed model is used. Is this correct? Thanks a lot in advance for your answer. Regards, Wolfgang Bandow CT-B / Berlin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: several gatekeepers
by Agboh, Charles 04 Jul '00

04 Jul '00

I was just kidding... Let me elaborate Both endpoints could be registered to different gatekeepers (different zones)each using the GRC model. Note that either gatekeeper could choose to use the DRC model. In this case, the gatekeeper using the DRC model would not be involved in the call signaling (Q.931 of H.225) and call control signaling (H.245) but would be receiving/sending service control signaling (RAS: IRR/IRG, ARQ/ACF, RRQ/RCF,DRQ/DCF...). In the DRC case it is a little difficult to provide some supplementary services independant of H.450.X. In the case of call transfer, the called party transfers the call to another endpoint sitting behind a GRC gatekeeper. In short, your assumption is correct. charles -----Original Message----- From: Wolfgang Bandow [mailto:wolfgang.bandow@DETEWE.DE] Sent: Tuesday, July 04, 2000 11:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: several gatekeepers Hello H.323-Experts, in connection with H.323 based IP-telephony in a PISN environment we came across the question whether it is permitted to have more than two Gatekeepers involved in a point to point H.323 connection. Is this in line with H.323 conventions? >From my point of view this situation also occurs in case of a call transfer, if the endpoints are located in different zones and the gatekeeper routed model is used. Is this correct? Thanks a lot in advance for your answer. Regards, Wolfgang Bandow CT-B / Berlin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: several gatekeepers
by Agboh, Charles 04 Jul '00

04 Jul '00

yes -----Original Message----- From: Wolfgang Bandow [mailto:wolfgang.bandow@DETEWE.DE] Sent: Tuesday, July 04, 2000 11:02 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: several gatekeepers Hello H.323-Experts, in connection with H.323 based IP-telephony in a PISN environment we came across the question whether it is permitted to have more than two Gatekeepers involved in a point to point H.323 connection. Is this in line with H.323 conventions? >From my point of view this situation also occurs in case of a call transfer, if the endpoints are located in different zones and the gatekeeper routed model is used. Is this correct? Thanks a lot in advance for your answer. Regards, Wolfgang Bandow CT-B / Berlin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Voice Signal Level in H323 Terminal/Gateway
by Shan Lu 03 Jul '00

03 Jul '00

Hi, I'd like to start a discussion on how to set speech signal level in an H323 environment. Speech signal level is an important part of QoS. It directly impacts end user's perception of how good the system works. It is also an integral part of interoperability testing. After the interoperability issues at the protocol level have been ironed out, the signal levels from different vendors have to "match" in order to provide true interoperability for end users. Some vendors make speech signal level a configurable parameter in their equipment and leave it to end user to decide. However, not all end users are capable of making intelligent decisions on this issue. When signal levels are set improperly, end users will complain about low volume, high volume, and/or echo. If the system consists of equipment from multiple vendors or involves interworking with PSTN/PBX, things can become complicated quickly. So a set of guidelines on how to determine speech level can benefit equipment manufacturers as well as their customers, including end users and service providers. I envision the guidelines should cover a number of topics: 1. desired end-end signal attenuation and acceptable range; 2. desired place of attenuation (tx or rx?) and how much; 3. desired level for DTMF and tones 4. desired level of echo cancellation; 5. connection scenarios: terminal-terminal, terminal-gateway, and gateway-gateway. Issues that we have to contend with include: end user acceptance, voice coder and echo cancellor optimal operation ranges, idle noise levels. For many of these issues, we can draw upon the wealth body of knowledge from the telephony world. Some of them may only take a reference to an existing standard. Others may require some serious thinking and, more importantly, agreement among multiple vendors. The discussion certainly is not restricted to voice only applications. But I am not sure if video has an interoperability issue as serious as voice. I am open to any suggestions. We may continue the discussion online or we can discuss face to face at SuperOp next week. Now here is my question #1: Is SourceInfo/DestinationInfo structure in H225 call setup messages a reliable way to distinguish end point type (terminal, gateway, gk)? What if in a GK-routed call? Does the GK modify that field? Thanks, Shan Lu NexTone Communications, Inc 9700 Great Seneca Highway Rockville, MD 20850 +1 240-453-6315 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: next revision of H.323 Annex H ?
by Jaakko Sundquist 03 Jul '00

03 Jul '00

Vineet et al, I'll try to work on it this week and maybe get it available by Friday. Sorry about the delay, but I had a couple of weeks of holiday and didn't feel like working on Annex H during that time. Furthermore, the mobility discussion seems to have been quite non-existent since Osaka, so I would really appreciate any contributions and/or discussions on the email reflector. -Jaakko > -----Original Message----- > From: EXT Kumar, Vineet [mailto:vineet.kumar@intel.com] > Sent: 21. June 2000 20:04 > To: Jaakko Sundquist (E-mail) > Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' > Subject: next revision of H.323 Annex H ? > > > Jaakko, > > When is the next revision of H.323 Annex H draft scheduled to > be out ? > > Regards, > vineet > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Deadlines
by Sakae OKUBO 03 Jul '00

03 Jul '00

Dear Q12-14/16 experts, I forgot to mention one thing regarding the meeting notice I just posted at the reflector. This time the deadlines for document registration and uploading are precisely specified as follows: /// Registration of the document: by 23:59 UTC, 11 August /// /// Distribution of the document: by 23:59 UTC, 14 August /// I am not a robot, but will basically manage the documents according to the meeting notice. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Notice of the Portland meeting in August 2000
by Sakae OKUBO 03 Jul '00

03 Jul '00

Dear Q12-14/16 experts, Please find attached the notice of the Portland meeting during 21-25 August 2000 as well as the logistic information from the host, Intel. The two files are also placed at the PictureTel ftp site: http://standard.pictel.com/ftp/avc-site/0008_Por/Notice_ITU-T_Portland.txt http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip Please note that you are required to send your participation registration and hotel room reservation by 7 August 2000. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. G. Meyer, Intel De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 3204 8194 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Sonus Networks 4400 Route 9 South Suite 1000 Freehold, NJ 07748 USA Tel: +1 732 409 5107 Fax: +1 732 409 5172 E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ------------------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting in Portland Date: 3 July 2000 ------------------------------------------------------------ Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Portland, USA at the kind invitation of Intel Corporation. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint session(s) with Q.12-14/16. 1. Date ^^^^^^^ 21 (Monday) - 25 (Friday) August 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ The Resort At The Mountain 68010 East Fairway Welches, OR 97067 Tel: +1-503-662-3101 (for messages) 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Toward determination in November: * H.323 Annex H (User, Service, and Terminal Mobility in H.323) * H.323 Annex I (Packet based MM Telephony over Error Prone Channels) * H.450.10 (Call Offer Supplementary Services) * H.450.11 (Call Intrusion) * H.450.12 (Common Information Additional Network) * H.225.0 Annex G V2 (Inter-domain) * H.323 Annex R (Robustness) * H.323 Annex M.3 (DSS1 Tunneling) * H.323 Annex E V2 (UDP call signaling) - Progress work for: * H.323 Annex N (QoS) * H.323 Annex O (Internet protocols and technologies complementary to H.323) * Other new items that may arise 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Toward determination in November: * H.248 Annex L * H.248 Annex M * H.235 V8 - Progress work for: * H.246 Annex D * H.248 V2 * H.341 V2 * other new items that may arise (e.g., new packages for H.248) 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 11 August /// /// Distribution of the document: by 23:59 UTC, 14 August /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 23:59 UTC, Friday 11 August at the latest. Document number (APC-nnnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Portland, 21-25 August 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Monday 14 August or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0008_Por directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along their laptop, 10BASE-T card and cord, and optionally wireless LAN card (please follow the host's advice). 6) The copying service is very limited and expensive at the meeting site. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 7 August 2000: Intel Meeting Service ATTN: Valerie Nester Fax: +1 480 554 7775 AND advise Rapporteurs of your attendance by e-mail: To: okubo(a)giti.or.jp, dskran(a)sonusnet.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Portland meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting secretariat together with the meeting registration. Special package room rate is $149.18 (single or double occupancy) per night including breakfast, tax and gratuity. The block reservation is held until 7 August. We are looking forward to meeting with you in Portland. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0