- sg16-avd - lists.packetizer.com

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

Delayed Contribution
by Callaghan, Robert 25 Jan '00

25 Jan '00

Mr. Okubo, I have uploaded a delayed contribution "H.450.8 Character set for Name Identification" proposing Unicode for this service. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0

FW: Last Call: RTP Payload for Text Conversation to Proposed Standard
by Gunnar Hellstrom 25 Jan '00

25 Jan '00

-----Original Message----- From: scoya(a)cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of The IESG Sent: Monday, January 24, 2000 7:56 PM To: IETF-Announce: ; Cc: rem-conf(a)es.net Subject: Last Call: RTP Payload for Text Conversation to Proposed Standard The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload for Text Conversation <draft-ietf-avt-rtp-text-03.txt> as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg(a)ietf.org or ietf(a)ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-03.txt

1 0

Reception of new/additional capability sets: delta or new
by Frank Derks 25 Jan '00

25 Jan '00

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

Delayed contributions or TDs
by Sakae OKUBO 25 Jan '00

25 Jan '00

Dear Q12-14 experts, When you have submitted your delayed contributions or TDs to ITU-TSB, could you please upload them to ftp://standard.pictel.com/avc-site/Incoming as well? Please announce your uploading through the reflector. This will facilitate review and comments by interested parties before the SG16 meeting to be held during 7-18 February. 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

H.323 Annex I ToR for approval at SG16 Geneva, 2000
by Barry Aronson 25 Jan '00

25 Jan '00

Dale, Please find attached a clean copy of the H.323 Annex I ToR. Per the Red Bank meeting, I changed the title to reflect the true nature of this annex and clarified the "Radio Network, 4." section. Unfortunately, I will not be able to attend the upcoming SG meeting in Geneva this February. Although I know of two efforts underway regarding technical contributions to H.323 Annex I, there seems to be little indication that much editorial work will arise during the meeting. My colleague, Hirokazu Tanaka will be in Geneva for part of the meeting and may be able to help if required if doing so does not conflict with his primary tasks. Please inform me of the impact of my absence if any. Also, I will be available via e-mail and phone during the meeting if needed. I apologize in advance if my absence causes any inconvenience. Barry Aronson Toshiba Corp. 33 Lake Shore Dr. Beverly, MA 01915-1907 USA Voice +1 978 232 3994 Fax +1 978 232 9220 Mobile +1 978 902 0768 (worldwide w/ GSM) H.320 1B: +1 978 232 3994 (by arrangement) 2B: +1 978 232 9220 (by arrangement) H.324 +1 978 232 9220 (by arrangement) E-mail: baronson(a)ieee.org

2 1