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

List of participants, Rapporteur meeting on 9-10 November
by Sakae OKUBO 26 Oct '00

26 Oct '00

Dear Q12-14/16 experts, Please review the attached list of registered participants for the 9-10 November Rapporteur meeting. If you are missing or you are not correctly represented, please immediately advise me. I will send the full list to Mr. Bigi, ITU-TSB, and then he will prepare badges for your participation in the meeting held at the ITU premises. I need your cooperation to avoid any confusion/trouble at the ITU building. The meeting notice <http://standard.pictel.com/ftp/avc-site/0011_Gen/Notice_0011_Geneva.zip> says that today is the deadline for your registration. 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 *********************************************************** ----------------------------------------------------------- Family First name name Country Organization ----------------------------------------------------------- Anderson Terry USA Lucent Technologies Audet Francois USA Nortel Networks Baese Gero Germany Siemens AG / ZT IK 2 Bougan Francois FRANCE France Telecom Callaghan Robert Germany Siemens AG Coldren Rex U.S.A. Lucent Technologies Delmond Frederic FRANCE France Telecom Euchner Martin Siemens Germany Even Roni Israel Accord Networks Fortinsky Michael Israel VocalTec Communications Ltd. Freundlich Glen USA Avaya, Inc. Gilman Robert USA Avaya, Inc. Groves Christian Sweden LM Ericsson Gu Qunshan USA PictureTel Corp. Harasaki Hidenobu Japan NEC Corporation Jones Paul USA Cisco Systems, Inc. Kawahara Toshiro Japan NTT DoCoMo, Inc. Klaghofer Karl Germany Siemens AG Korpi Juha Germany Siemens AG Leibovitch Ilana Israel MOC (ECI Telecom) Levin Orit Israel RADVision Li Adam Hengkong Korea Samsung Electronics Lindbergh Dave USA PICTURETEL CORP. Maeng Joon USA VTEL Corp. Michaely Boaz Israel Comverse Network Systems (for SG meeting: Israel Ministry of Communication) Minono Satoshi Japan Oki Electric Industry Co.,Ltd Modahala Loganathan USA Cisco Systems, Inc. Okubo Sakae Japan TAO Waseda Research Center Park Jeong-Hoon Korea Samsung Electronics Potter Morgan UK BT Roelands Marc Belgium Siemens Roy Radhika R. USA AT&T Sayre Clifford USA Lucent Technologies Segers John The Netherlands Lucent Technologies Skran Dale USA Sonus Netwoks Sundquist Jaakko Finland Nokia Suzuki Takashi Japan NTT DoCoMo, Inc. ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1956(Adding ServiceControl fields to LRJ/LCF) uploaded
by Satoshi Minono 26 Oct '00

26 Oct '00

Dear Mr.Skjaeran, Please excuse my delay in answering your e-mail (Annex K over multiple domains). We have read your comments carefully and agree to them. I have posted APC-1956 (Adding ServiceControl fields to LRJ/LCF) to the Incoming directory of PictureTel ftp site. Thank you. Best regards, Satoshi Minono ---------------------------------------------------------------------------- -- Oki Electric Industry Co.,Ltd. Tel:+81-3-3454-2111 Fax:+81-3-3798-7684 e-mail:minono888@oki.co.jp

1 0

Re: request APC for 'Service Zone'
by Sakae OKUBO 25 Oct '00

25 Oct '00

Dear Mr. Michaely, Mr. Baese, Mr. Segers, In response to your requests, the following APC numbers have been allocated tor your contributions. We are approaching a new millennium! APC-1990 Comverse Network Systems H.225.0 Annex G v2: support for Service Zone APC-1991 Comverse Network Systems H.225.0 v4: Enhancing SupportedProtocols to indicate video APC-1992 Siemens {to be advised} APC-1993 Siemens {to be advised} APC-1994 Siemens {to be advised} APC-1995 Lucent Technologies Issues for H.248 implementors' guide 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

Re: Sanity check on Packet Sizes....
by Rosen, Brian 25 Oct '00

25 Oct '00

There is the "real" answer, and the practical answer. The real answer is that depending on what kind of network you are on, you could see, in theory, packets of up to 64K bytes. 4K bytes can actually be seen in some Gig-E systems. Whether you will find a video codec using such large packets sizes or not is uncertain; I've never seen one. It used to be that we thought 1510-odd bytes was the biggest practical packet you see on a LAN, but that's no longer the case. There is a lot of code around that fails above that 1500 ish number. Brian > -----Original Message----- > From: Chris Farmer [mailto:cfarmer@smithmicro.com] > Sent: Wednesday, October 25, 2000 9:05 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Sanity check on Packet Sizes.... > > > Okay, > > I was researching an arcane fact on the theoretical and > practical sizes for > RTP packet sizes for > video conferencing. > > What I have come up with is: > There is specific RFC's about implimenting H.263, H.261, > G.723, but I'm > looking for just an overall > practical size to check input buffer sizes. > > RFC 1889 RTP packet structure referes to 768, RFC 791 > RFC 768 UDP refers to obsolete RFC 760. > RFC 791 states in the Glossory, > ARPANET messages max size is about 1012 octets (8096)bits. > ARPANET packet max size is about 126 octets (1008) bits. > > As a client side EP, should I be concerned about the ARPANET > message size or > the ARPANET packet size? > > RFC 760 states: > 65,536 octets theoretically, put not practical > Page 22, every destination should be able to > receive a datagram > of 576 octets in one piece or as fragments to be reassembled > > so my guess here is 4608 bits max? Or is this too low level > and there is > another RFC that I should reference? > > Any help in this direction? > > Thanks, > > > Christopher B. Farmer > Software Engineer > Smith Micro Software, Inc. > (503) 641-1221 ext 28 > ====================================================================== > Daily C\C++ Tidbits at www.EngageUs.com\c > "Challenges in life are inevitable. Failure is optional" - > Roger Crawford > ====================================================================== > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Sanity check on Packet Sizes....
by Chris Farmer 25 Oct '00

25 Oct '00

Okay, I was researching an arcane fact on the theoretical and practical sizes for RTP packet sizes for video conferencing. What I have come up with is: There is specific RFC's about implimenting H.263, H.261, G.723, but I'm looking for just an overall practical size to check input buffer sizes. RFC 1889 RTP packet structure referes to 768, RFC 791 RFC 768 UDP refers to obsolete RFC 760. RFC 791 states in the Glossory, ARPANET messages max size is about 1012 octets (8096)bits. ARPANET packet max size is about 126 octets (1008) bits. As a client side EP, should I be concerned about the ARPANET message size or the ARPANET packet size? RFC 760 states: 65,536 octets theoretically, put not practical Page 22, every destination should be able to receive a datagram of 576 octets in one piece or as fragments to be reassembled so my guess here is 4608 bits max? Or is this too low level and there is another RFC that I should reference? Any help in this direction? Thanks, Christopher B. Farmer Software Engineer Smith Micro Software, Inc. (503) 641-1221 ext 28 ====================================================================== Daily C\C++ Tidbits at www.EngageUs.com\c "Challenges in life are inevitable. Failure is optional" - Roger Crawford ====================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323V4 error (prior message mistitled)
by Wuerfel, Randy P 25 Oct '00

25 Oct '00

(THIS IS A REPEAT MESSAGE, THE FIRST HAD THE WRONG SUBJECT) In reading H.323V4 (from APC-1874), I noticed in the procedures of section 10.4.3 (tunneling of a signalling protocol in H.225.0 call signalling messages) a reference to a tunnelledRequired flag, which doesn't exist. Can the following change be made to H.323V4, or at least captured in the Implementers Guide (assuming this error has not already been corrected)? Section 10.4.3, second paragraph: If an endpoint will only allow the call to proceed if tunneling is supported, it shall set the tunnellingRequired flag in the Setup message; the tunnelledRequired (DELETE) tunnellingRequired (REPLACEMENT) flag shall not be included in any other message than Setup. If an endpoint receives a tunnelledSignallingMessage with the tunnellingRequired flag set in the Setup message and is not able to tunnel the protocol, it shall terminate the call by sending a Release Complete with a reason of tunnelledSignallingRejected; a tunnellingRequired flag in any other message than Setup shall be ignored. Regards, Randy Wuerfel ========================================================== Siemens Information and Broadband, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: PictureTel contributions uploaded
by Wuerfel, Randy P 25 Oct '00

25 Oct '00

In reading H.323V4 (from APC-1874), I noticed in the procedures of section 10.4.3 (tunneling of a signalling protocol in H.225.0 call signalling messages) a reference to a tunnelledRequired flag, which doesn't exist. Can the following change be made to H.323V4, or at least captured in the Implementers Guide (assuming this error has not already been corrected)? Section 10.4.3, second paragraph: If an endpoint will only allow the call to proceed if tunneling is supported, it shall set the tunnellingRequired flag in the Setup message; the tunnelledRequired tunnellingRequired flag shall not be included in any other message than Setup. If an endpoint receives a tunnelledSignallingMessage with the tunnellingRequired flag set in the Setup message and is not able to tunnel the protocol, it shall terminate the call by sending a Release Complete with a reason of tunnelledSignallingRejected; a tunnellingRequired flag in any other message than Setup shall be ignored. Regards, Randy Wuerfel Randy Wuerfel Siemens Enterprise Networks 4900 Old Ironsides Drive Fax: (408) 492-4666 M/S 200 Tel: (408) 492-4375 P.O. Box 58075 E-mail: Randy.P.Wuerfel(a)icn.siemens.com Santa Clara, CA 95052-8075 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

PictureTel contributions uploaded
by Patrick_Luthi＠PICTEL.COM 25 Oct '00

25 Oct '00

Dear experts, The following contributions have been uploaded to the AVC-site/incoming: APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 See you in Geneva! Patrick Luthi PictureTel Corp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Last Call On NAS Package
by Tom-PT Taylor 25 Oct '00

25 Oct '00

There have been no comments on draft-ietf-megaco-naspkg-01.txt. I am therefore submitting it to WG Last Call, expiring Nov. 8/00. I think our intention is that this be a Standards Track item, so speak up if you disagree. Tom Taylor

1 0

Re: Video experts: Proposal to add video to Desired/SupportedProt ocols
by Roni Even 25 Oct '00

25 Oct '00

Paul & Boaz, The supported protocol structure was defined for registering gateways at the gatekeeper. This enabled the gateway to define which protocol it supports and which rates - see gatewayinfo structure. In version 4 Orit has asked have the same capability for MCU and to add supported protocols to the mcuInfo structure. As Paul states the use of this structure was added to other RAS calls for different reasons, to signal which protocols will be needed for the call, mostly Fax so it can be routed through a gateway with the right support. The voice part that Boaz mention is to specify the capability to support non multiplexed voice (not H.320) or PSTN call on the switched network side and not for voice only in H.323. Notice that all the information is about protocols and rates and not about video or audio algorithms. I understand what Boaz is suggesting but agree with Paul that the structures today are not supporting it. Furthermore I would claim that the initial design requires that H.320/ H.323 gateways will be able to route at least G.711 and H.261 CIF the mandatory codec and that is why there will be no problem with routing the call. Fax support is not mandatory and that is why the information is needed. I think that the idea of the originating endpoint trying to define the call capability will be a problem with the protocol and with the end to end solution. The capability negotiation is there to find the optimal communication mode. If the gateway support H.323 and voice protocols only it means that it can do only voice calls. So if the endpoint will request, according to the current proposal, in the requested protocol voice and not H.320 then the gatekeeper will not need to route it to a gateway supporting H.320. To summarize I cannot see a need for such information. Thanks Roni Even -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, October 25, 2000 6:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Video experts: Proposal to add video to Desired/SupportedProtocols Boaz, I agree with such a proposal-- I need to look at the details a bit more closely, but there is definitely a need to be able to signal at the outset of a call what kind of resources are needed. One of the primary reasons for this original text was so that, when a fax call was going to be placed, we could better guarantee that we would get routed to a gateway that supports fax. The names of the structures and fields were derived from already existing structures. One thing to note is that you also need to consider capacity. Endpoints have the ability to report capacity. We would need to be able to report on what "video capacity" is available. Also, the "SupportedProtocols" is a choice. I would guess, though, that you would want to include "voice" and "video" at the same time-- certainly, H.320 and video at the same time makes sense. In any case, we need to have some way of logically indicating the capacity and also indicating what resources are expected to be consumed in a call. Paul ----- Original Message ----- From: "Boaz Michaely" <boaz.michaely(a)ties.itu.ch> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, October 24, 2000 3:14 PM Subject: Video experts: Proposal to add video to Desired/SupportedProtocols > Hi all, > I would like some feedback from the video experts for a contribution I wish to > make to expand SupportedProtocols, which has recently been added for use in > ARQ, LRQ, SETUP, and Annex G Access Request messages. (ref: D-347 of 0200_Gen) > > > "desiredProtocols - Identifies the type of protocols, in order of preference, > the originating endpoint desires for its call (e.g., voice or fax). A > resolving entity may use this field to locate an endpoint that also supports > the protocol, giving consideration to the order of preference." > > Correct me if I'm wrong, but it seems that the objective of this addition, as > documented in D-347 is not fully achieved, since video capabilities cannot be > expressed. (it also strikes me that *protocols* may not be the best description > of the capabilities being negotiated here.) > > If we were to complete the proposal, the change would probably look as below. > My specific question to the video experts: What should the VideoCaps structure > contain and how would it be used (clearly we do not intend to replace H.245 > here). Thus, is there any good reason to conform to the structure of VoiceCaps - > including the location of the '...' and the inclusion of 'SupportedPrefixes' ? > (is it ever used ?) > > > SupportedProtocols ::= CHOICE > { > nonStandardData NonStandardParameter, > h310 H310Caps, > h320 H320Caps, > h321 H321Caps, > h322 H322Caps, > h323 H323Caps, > h324 H324Caps, > voice VoiceCaps, > t120-only T120OnlyCaps, > ..., > nonStandardProtocol NonStandardProtocol, > t38FaxAnnexbOnly T38FaxAnnexbOnlyCaps > ---BEGIN > , > video VideoCaps > ---END > } > > VoiceCaps ::= SEQUENCE > { > nonStandardData NonStandardParameter OPTIONAL, > ..., > dataRatesSupported SEQUENCE OF DataRate OPTIONAL, > supportedPrefixes SEQUENCE OF SupportedPrefix > } > > ---BEGIN > VideoCaps ::= SEQUENCE > { > nonStandardData NonStandardParameter OPTIONAL, > ..., > dataRatesSupported SEQUENCE OF DataRate OPTIONAL, > supportedPrefixes SEQUENCE OF SupportedPrefix > } > > ---END > > > Boaz Michaely > Senior System Architect, Corporate > Comverse Network Systems > Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44 > mailto:boaz.michaely@ties.itu.int > http://people.itu.int/~michaely > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0