May 1999 - sg16-avd - lists.packetizer.com

Re: caller ID and implementer's guide
by Paul Long 06 May '99

06 May '99

Glen, Yes, this would definitely be a problem. As you know, 7.2.2.1/H.225.0v2 says, "Information transfer capability (octet #3) - The extension bit (bit 8) shall be set to '1'." Our EP expects the remote entity to set it correctly. If it's not, we assume that the SETUP is "bad" and clear the call by sending RELEASE COMPLETE. This goes for all changes being considered: a new Recommendation revision can augment and clarify but never modify the behavior defined by the previous revision. There is so much development effort in the H.323 world that you can't make a change simply because nobody responded to your query on the reflector. Please do not risk breaking implementations by modifying the Recommendation, no matter how obscure those modifications seem. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Glen Freundlich [SMTP:ggf@LUCENT.COM] Sent: Thursday, May 06, 1999 3:11 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: caller ID and implementer's guide At the Monterey meeting we discussed the possibility of an addition to the Implementer's Guide to support caller ID features (APC-1527). H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party Number IE (and also specifies that the octet 3 extension bit shall be set to 1). The proposal calls for removing the restriction through the Implementer's Guide. (See also the meeting report in APC-1554b.) Fixing this brings up the possibility of interoperability problems with existing products. Please respond if you think this change will be a problem. You can respond to me individually, rather than to the entire list, if you prefer. Thanks, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

caller ID and implementer's guide
by Glen Freundlich 06 May '99

06 May '99

At the Monterey meeting we discussed the possibility of an addition to the Implementer's Guide to support caller ID features (APC-1527). H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party Number IE (and also specifies that the octet 3 extension bit shall be set to 1). The proposal calls for removing the restriction through the Implementer's Guide. (See also the meeting report in APC-1554b.) Fixing this brings up the possibility of interoperability problems with existing products. Please respond if you think this change will be a problem. You can respond to me individually, rather than to the entire list, if you prefer. Thanks, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Drafat H.450.8
by Sakae OKUBO 06 May '99

06 May '99

Dear Q.12-14/16 experts, The following document for the SG16 Santiago meeting has been placed at the PictureTel ftp site: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ Source: Editor Title: Draft new Recommendation H.450.8 (for determination) Conference out of Consultation Supplementary Service for H.323 (SS-CoC) Type: TD File: DraftH.450.8.zip Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: flowControlCommand and packet overhead
by Paul Long 06 May '99

06 May '99

Steve, But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead On Wed, 28 Apr 1999, Paul Long wrote: > Therefore, clarification text to the following effect should be added to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead." I'm mostly a lurker on this list, but I thought I would offer another perspective. The RTP spec, RFC 1889, says the following: Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels. At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to know how much overhead the additional headers will add. -- Steve

1 0

H.323 AnnexD & mandatory fax OpenLogicalChannel elements
by joachim.fabini＠SEA.ERICSSON.SE 06 May '99

06 May '99

Hi all, >From H.323 AnnexD, D.7: "The H.323 AnnexD gateway shall send both a voice and a fax OpenLogicalChannel element in the setup message". Could anyone envolved in the development of AnnexD please outline the facts behind the _mandatory_ voice _and_ fax OpenLogicalChannel elements? Does this really mean that a H.323 gateway needs to open (or, at least offer) a fax channel beside each voice call if it intends to be also AnnexD compliant? The gateway can decide on the type (voice, fax) of the connection anyhow only _after_ the end-to-end voice channels are connected. Thanks in advance, Regards --Joachim Fabini --------------------------------------- Joachim Fabini Ericsson Austria AG Pottendorfer Strasse 25-27 A-1121 Vienna, Austria voice: +43 1 81100-5127 fax: +43 1 81100-4686 email: Joachim.Fabini(a)ericsson.com ---------------------------------------

1 0

Mr. Tosco's WP2 workplan
by Sakae OKUBO 06 May '99

06 May '99

Dear Q.12-14/16 experts, Attached please find Mr. Tosco's draft workplan received some weeks ago (apologies for this delayed distribution). Please note that it is a draft subject to change according to the need identified. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Useful information from Mr. Campos-Neto via Mr. Sullivan
by Sakae OKUBO 06 May '99

06 May '99

Date: Tue, 27 Apr 1999 11:12:27 -0400 From: garys(a)python.pictel.com (Gary Sullivan) To: itu-adv-video(a)standard.pictel.com Subject: [wg5-3: 2824] Q15: Amd. Administratrivia II Santiago May 99 Sender: owner-wg5-3(a)inetserv.ttc.or.jp Precedence: bulk ITU-T Advanced Video Coding Experts Group (Q.15/SG16) Email from garys(a)python.pictel.com (Gary Sullivan): A forwarded message from our Working Party Chairman: -Gary S. >----------------------------------------- >From: Simao Campos <simao(a)ctd.comsat.com> >Subject: [Q.20/16] Amd. Administratrivia II Santiago May 99 >Date: Sat, 17 Apr 1999 09:52:00 -0400 Dear colleagues, Fixing an error and a clarification on my previous messgae. Simao -- A quick update for the upcoming SG 16 meeting: - the workshop has been confirmed for the 17th May, for those interested in attending. Also, please notice that there will be a SG 16 Welcome dinner on Wed May 19 and a farewell lunch on Sat May 29. - now you can submit contributions to the ITU via a WEB browser. Fill in the form at http://www.itu.int/ITU-T/edh/ . See http://www.itu.int/ITU-T/edh/ for a Q&A on submission methods, and TSB Circular Letter 182 as well (a must-see) -- check at http://www.itu.int/itudoc/itu-t/circ/circ4/182.html. - Also, please be sure to use the appropriate ITU-provided templates (see http://www.itu.int/itudoc/itu-t/template/index.html) and A4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ paper size when composing you documents. Also, be aware that documents prepared with Word 97, even if saved in the Word 6/95 format, may loose information when read by Word 95 [aka Word 7] (even though it may *look* OK in Word 97!!!). This is especially true if you try to use the Word 97 embedded drawing tools. DON'T! INSTEAD, use an external drawing package and import the picture into the document. And always provide them as individual files to the ITU, when you submit the document. When in doubt, also provided the ITU with a printable version of your document, e.g. postscript or Acrobat .PDF files. I had this grief many times, not to mention that it took me time to make sure some other people's documents had their missing figures recovered. So please, be careful, or your document may show up not exactly as you hoped for ... :-) NOTE on templates: ^^^^^^^^^^^^^^^^^^^ If they look funny on your screen, try the following in Windows95/NT: exit Word, then open Control Panel, double-click Regional Settings, select the tab "Number". Go to the last item in the menu ("LIst Separator") and change whatever character is in there (probably a comma ",") to a semi-colon (";"). Click OK, reopen the template; it should look "familiar" now. That's what I had for the moment. Any questions or problems, drop me a line. Best regards, Simao Campos-Neto ---------------------------------------------------------------------------- ---- *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) Email List Message *** To send messages, address them to "itu-adv-video(a)standard.pictel.com". To subscribe or unsubscribe, send email to "majordomo(a)standard.pictel.com". Note: Only people whose exact email address is subscribed to the list can post. Subscriptions: "subscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message body. Unsubscriptions: "unsubscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message body. ---------------------------------------------------------------------------- ----

1 0

flowControlCommand and packet overhead
by Paul Long 05 May '99

05 May '99

In response to a private query, I discovered that there is a minor oversight in H.323 regarding whether the flowControlCommand includes packet overhead. Here's what it says about the open logical channel bitrate and ARQ bandwidth parameters, respectively, which can be used to determine the intent for FlowControlCommand: 6.2.11.2/H.323v2: "The limit applies to the information streams which are the content of the logical channel(s), not including RTP headers, RTP payload headers and network headers and other overhead." 7.2.4/H.323v2: "This is an upper limit on the aggregate bitrate for all transmitted and received, audio and video channels excluding any RTP headers, RTP payload headers, network headers, and other overhead." Therefore, clarification text to the following effect should be added to 6.2.11.2 (in v2) of H.323: "flowControlCommand applies to the information streams which are the content of logical channel(s), not including RTP headers, RTP payload headers, network headers and other overhead." Practically speaking, though, it appears that most vendors violate H.323 by ignoring this command altogether, so one is doing very well indeed at least attempting to obey it with or without counting overhead. Note that in H.324 the limit includes packet overhead when applied to the entire mux but not when applied to an individual channel; however, in H.323 the limit never includes overhead. IMO, H.324 makes more sense, but I suppose in H.323 one may not know exactly how much overhead is added by a lower layer, e.g., the UDP/IP headers added by the sockets layer, and also because H.323 is ostensibly transport-layer independent. Paul Long Smith Micro Software, Inc.

2 1

RTP MIB status
by Stephen Casner 05 May '99

05 May '99

I expect that the MIB for RTP has been discussed in SG16 already as part of H.341, but I wanted to let you know that the draft is now in last call for comments in the AVT working group of IETF. Comments from participants here are welcome (send to rem-conf(a)es.net or the authors listed in the draft). The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-05.txt The next step after working group comments are resolved is to submit for publication as an RFC, which results in an IETF-wide last call. Steve Casner, AVT co-chair

1 0

Documents for the Santiago meeting
by Sakae OKUBO 05 May '99

05 May '99

Dear Q.12-14/16 experts, I have placed the following files at the ftp site. ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ SOURCE: United States of America TITLE: Correction of problems related to MCV in the white draft of H.230 TYPE: Delayed Contribution FILE: Delayed_H230.zip SOURCE: Toshiba, NEC, NTT DoCoMo TITLE: Proposed editorial revisions on H.245 version 5 regarding MPEG-4 visual codepoints and the generic capability TYPE: Delayed Contribution FILE: h245v5decision-correction.zip SOURCE: Motorola, Cisco TITLE: Comments upon H.323 Annex E TYPE: Delayed Contribution FILE: WG16_comm_annexE.zip SOURCE: LM Ericsson TITLE: DRAFT NEW ANNEX C FOR THE H.246 RECOMMENDATION TYPE: Delayed Contribution FILE: h246_annex_c_v_0-1.zip SOURCE: Q.13 Rapporteur TITLE: Editorial Changes to H.225.0 Annex G TYPE: TD FILE: annexg_editor_contribution2.zip Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

2 1