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

Re: security contributions uploaded
by Sakae OKUBO 26 Jan '00

26 Jan '00

Dear Mr. Euchner, >The following two files were not uploaded correctly due to a transfer >interrupt on bad IP-connections >ftp://standard.pictel.com/avc-site/Incoming/contrib_H235v2_IETF_Refs.doc ><ftp://standard.pictel.com/avc-site/Incoming/contrib_H235v2_IETF_Refs.doc> >ftp://standard.pictel.com/avc-site/Incoming/Draft_H323AnnexJ.zip ><ftp://standard.pictel.com/avc-site/Incoming/Draft_H323AnnexJ.zip> >(published as COM 16-114-E) > >I've attached both files again and ask you to replace the corrupt ones with >these ones attached, as I was not allowed to replace my own files in the >incoming directory. Actioned as requested. 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 ***********************************************************

1 0

Delayed Contributions and TDs
by Sakae OKUBO 25 Jan '00

25 Jan '00

Dear Contributors, Thank you for uploading your documents to the PictureTel avc-site. Please note, however, that this is just for the convenience of experts, NOT the official submission to the ITU-TSB. Documents for the SG level meeting shall reach Mr. Bigi, ITU-TSB, for consideration by the meeting. 1. Delayed Contributions They are sourced by ITU-T member(s) and shall reach TSB not later than 26 January 2000 (today) after going through national procedures of the nation of the source. 2. Temporary Documents They are sourced by Rapporteur(s) and accepted before the meeting, or even during the meeting. All the materials for decision shall be made available at the start of the meeting. We should count the time necessary for large reproduction at the SG meeting. For either case, methods of electronic submission are detailed in TSB Circular 182 (http://www.itu.int/itudoc/itu-t/circ/circ4/182.html) The easiest way is to send an e-mail with your contribution as attachment to Mr. Bigi (Fabio.Bigi(a)itu.int) and TSB-EDH (tsbedh(a)itu.int) 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 ***********************************************************

1 0

Delayed contribution from Hitachi
by toshiaki 25 Jan '00

25 Jan '00

Dear Q12,13 experts, I just uploaded delayed contribution (Hitachi_Layer.zip) to the AVC/Incoming site. The document has the following Title: "H.262 layered video transmission depending on the size of a video picture" Best Regards, -- *** Toshiaki Suzuki (toshiaki(a)crl.hitachi.co.jp) *** *** Hitachi, Ltd., Central Research Laboratory *** *** Network Systems Research Department *** *** Phone: +81-42-323-1111/ Fax: +81-42-327-7740 ***

1 0

None
by Selvam Rengasami 25 Jan '00

25 Jan '00

Mr. Okubo, Per your request, I have uploaded my delayed contributions to the AVC site. The filenames are: telcordia-h248-announcements.DOC telcordia-h248-callerid.DOC telcordia-h248-callinfo.DOC telcordia-h248-misc-cmts.DOC telcordia-h248-tones.DOC telcordia-h248_asn1-tagging.DOC One of files did not originally upload properly and therefore it appears that there are two nearly identical files. The correct file regarding the ASN.1 is 170kb and is titled (telcordia-h248_asn1-tagging.DOC ). The one that needs to be reomved from teh website if 43 kb and is titled (telcordia-248-asn1-tagging.DOC). Best Regards, Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 E-mail: srengasa(a)telcordia.com

1 0

Re: Reception of new/additional capability sets: delta or new
by Paul Long 25 Jan '00

25 Jan '00

Frank, Search for "delta" on this page: http://web2.airmail.net/plong/h245impl.html Paul Long Smith Micro Software, Inc. -----Original Message----- From: Frank Derks To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 1/25/00 1:57 AM Subject: Reception of new/additional capability sets: delta or new In previous discussions on this list it was often stated that newly/additional received capability sets are a delta. What is not clear, however, is a delta with respect to what. E.g. is this a delta with respect to the previously sent TCS or is this a delta with respect to the "used-up" capabilities by the terminal that receives the TCS. Furthermore, if it is a delta, then how do I remove capabilities from a set? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

Contributions
by Francois Audet 25 Jan '00

25 Jan '00

Colleagues, I have uploaded the following delayed contributions on the server: - Proposed modifications to generic signalling tunnelling mechanism in H.323v4 and H.225.0v4 - Proposed modifications to H.323 Annex M The files are: http://standard.pictel.com/ftp/avc-site/Incoming/d-GenTunMech.doc http://standard.pictel.com/ftp/avc-site/Incoming/d-h323VI.doc They will later be moved to: http://standard.pictel.com/ftp/avc-site/0002_Gen/d-GenTunMech.doc http://standard.pictel.com/ftp/avc-site/0002_Gen/dh323VI.doc ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

delayed contributions
by Glen Freundlich 25 Jan '00

25 Jan '00

Colleagues, I have uploaded a number of delayed contributions to the avc ftp site: Annc2.zip: Announcement and Tone Support for H.323 AnnexG_ref_points.zip: Reference Points for the use of H.225.0 Annex G Refs.zip: References to TIA/EIA Standards in ITU-T Recommendations Compliance with Recommendations A.5 and A.4 Revised.zip: H.245 Generic Capabilities Definition and H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) packetization.zip: Alignment with IETF of H.225 Packetization Definitions in APC-1568 (TDMA Vocoders) and APC-1650 (CDMA Vocoder) wirelessbe.zip: Border Elements for Wireless H.323 Administrative Domains wirelessreg.zip: Registration Procedure for Wireless Mobile H.323 Terminals Regards, 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

Uploaded Delayed Contributions for February Meeting
by Jill Caugherty 25 Jan '00

25 Jan '00

Mr. Okubo and colleagues, I have uploaded my delayed H.323 SG16 contributions to the AVC site. ( ftp://standard.pictel.com/avc-site/Incoming) The filenames are: CallSignalling-2000.zip FastConnect-2000.zip RSVP-2000.zip SupportAltGK-2000.zip SupportedPrefixes-2000.zip desiredProto-2000.zip Regards, Jill Caugherty -- ------------------------------------------------------------------ Jill Caugherty | | | jcaugher(a)cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:. 919-472-5705 fax: 919-472-2177 | c i s c o S y s t e m s ------------------------------------------------------------------

1 0

Delayed Contribution
by Karl.Klaghofer＠ICN.SIEMENS.DE 25 Jan '00

25 Jan '00

Dear Mr. Okubo, I have uploaded a Delayed Contribution "Call Linkage in H.323" to the "Incoming" directory. Regards, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

[Robustness] Minutes for the robustness telecon -- January 6, 200 0
by Maureen Stillman 25 Jan '00

25 Jan '00

Minutes of H.323 Robustness Teleconference - January 6, 2000 Prepared by Maureen Stillman, Nokia Next Teleconference: Not scheduled. We will be meeting in working sessions in Geneva February 7-18. The times and place will be determined and announced at the SG-16 meeting. Action items from this teleconference: 1. Post meeting minutes to mailing list 2. Radvision to submit technical input entitled "Robustness Procedure" to SG-16 meeting in Geneva by January 27. Attending the 1/6/2000 teleconference (some names are missing from this list): Rich Bowen rkbowen(a)cisco.com Jill Caugherty jcaugher(a)cisco.com Jean-François Mulé jfm(a)clarent.com Vineet Kumar vineet.kumar(a)intel.com Robert Callaghan Robert.Callaghan(a)ICN.siemens.com Maureen Stillman maureen.stillman(a)nokia.com Jorg Ott jo(a)tzi.uni-bremen.de Michael Fortinsky Michael_Fortinsky(a)vocaltec.com Sasha Ruditsky at Radvision Roy Radhika rrroy(a)att.com Summary of Teleconference: We discussed the draft submission to SG-16 Geneva meeting written by Radvision incorporating discussions from the last several robustness teleconferences. We decided to ask Radvision to submit this input to the Geneva meeting by the deadline of January 27, 2000. Radvision agreed to do this. There will be a debate on robustness at the Geneva meeting and working group sessions. Jorg Ott and Robert Callaghan will schedule a meeting with Dale Skran to determine if robustness should be proposed as modifications to the text in H.323, H.225, etc. or if it should be a proposed Annex to H.323. We decided that we would work in a working group session during the Geneva meeting February 7-February 18 and possibly meet on Saturday, February 12 to further the robustness effort. There will be no scheduled teleconference before the February Geneva meeting. Scope of the SG-16 Robustness Group: The Study Group 16 robustness working subgroup is tasked with defining robustness mechanisms that handle system failures that are visible "on the wire". For example, if a fault tolerant mechanism invokes a hardware/software solution that makes the switchover or recovery "transparent" to the network, then this is fine and out of the scope of the working group. Scope of the RadVision Submission: This submission defines a robustness procedure for the following problem: Corporate Environment - calls can be gatekeeper or direct routed; H.225 up and running; might be using fastconnect; two endpoints have a call in progress Gatekeeper or endpoint goes down or fails - the two endpoints lose the call signaling channel We agree that such a call needs to be continued - how this should be done is a problem that needs to be solved. How can we recover the call from this scenario? . Overview of the submission: This submission specifies a procedure to keep point-to-point calls alive (non-conference calls) in case of a failure of an endpoint or gatekeeper. If one of the components involved does not support robustness mechanisms, then the call is terminated. If an endpoint supports robustness mechanisms, it indicates this in the registration process for the gatekeeper (RRQ message). When the gatekeeper responds with a confirmation (RCF message) it indicates whether or not the GK supports robustness procedures. The following robustness procedure is implemented. We assume that the failed component knows that it has failed and initiates the robustness procedure. The failed component initiates an exchange of Q.931 Status Inquiry/Status messages. The Status message indicates the call state of the endpoint. Table 4-8 of the Q.931 standard defines all the possible call states. At the end of this call state exchange each endpoint can determine the call state of the interrupted call at the other endpoint. The submission defines two state tables - one is used by the incoming call endpoint and the other is used by the outgoing call endpoint. The table indicates which message(s), if any, to send to the other endpoint or gatekeeper based on the current call state of the incoming and outgoing endpoints (which they learned by exchanging Q.931 status messages). The effect of this message exchange will be to recover the call state and allow the call to continue (however, supplementary services are not guaranteed to work). The robustness procedure must close the prior open H.225 call signaling channel (if there was one) and reopen a new one. If the call had a prior open H.245 connection, then the H.245 connection needs to be closed and a new one reopened. If this was a fastconnect channel, then the new H.225 channel needs to be a fastconnect channel. (See the robustness submission for further details.) -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0