- sg16-avd - lists.packetizer.com

Re: [VideoPhone:3843] Re: [QOS] New reject reasons in QOS proposal
by Yuichiro-Tuck-Takagawa 31 Jan '00

31 Jan '00

I have already asked to stop this to the network manager. At 14:17 00/1/31 +0800, Liping Wang wrote: > somebody please stop it. > > > -----Original Message----- > > From: Gilles Delmas [SMTP:gilles.delmas@PHILIPS.COM] > > Sent: Monday, January 31, 2000 2:11 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [QOS] New reject reasons in QOS proposal > > > > > > Status Distribution January 31, 2000 07:09:04 > > > > Sent by EMAUO01 > > > > The message regarding "[QOS] New reject reasons in QOS proposal" sent on > > January 31, 2000 07:09:04 was sent by > > > > Status Recipient > > Type To > > Native Name ITU-SG16(a)MAILBAG.INTEL.COM > > Foreign Native Name ITU-SG16(a)MAILBAG.INTEL.COM/n/n/nSMTP > > > > > > > > Recipients > > > > Status Reporters > > Type From > > Name Domain LOTUS > > Native Name CN=Gilles > > Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1 > > Foreign Native Name CN=Gilles > > Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS/nEMEA1/n/n > > Organization PHILIPS > > Org Unit 1 RESEARCH > > Org Unit 2 LIM > > Last Name Delmas > > First Name Gilles > > > > > > > > Status 769 > > Explanation Invalid recipient > > > > X.400 Status 769 > > Explanation Error delivering to SUR003M/M/SERVER/PHILIPS > > mail5/gillesdelmas.nsf; File truncated - file may have been damaged *************************************************************** Yuichiro "Tuck" Takagawa y.takagawa(a)east.ntt.co.jp NTT-East Japan Corporation Voice/Wireless: $B!! (B+81-(0)90-3248-6357 Wired:+81-(0)3-3277-2420 Emergency Internet Pager: 0361241374(a)page.docomonet.or.jp Home Page: http://village.infoweb.or.jp/~fwbc7006/index.htm Post: UOB, 2-2-2 Otemachi, Chiyoda-ku, Tokyo100-0004, Japan MAPION URL: http://www.mapion.co.jp/cgi-bin/m?no=2b1448-22nuxd GPS Data: N035 $B!k (B40 $B!l (B58 $B!m!! (BE139 $B!k (B46 $B!l (B16 $B!m (B ***************************************************************

1 0

Re: [QOS] New reject reasons in QOS proposal
by Liping Wang 31 Jan '00

31 Jan '00

somebody please stop it. > -----Original Message----- > From: Gilles Delmas [SMTP:gilles.delmas@PHILIPS.COM] > Sent: Monday, January 31, 2000 2:11 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [QOS] New reject reasons in QOS proposal > > > Status Distribution January 31, 2000 07:09:04 > > Sent by EMAUO01 > > The message regarding "[QOS] New reject reasons in QOS proposal" sent on > January 31, 2000 07:09:04 was sent by > > Status Recipient > Type To > Native Name ITU-SG16(a)MAILBAG.INTEL.COM > Foreign Native Name ITU-SG16(a)MAILBAG.INTEL.COM/n/n/nSMTP > > > > Recipients > > Status Reporters > Type From > Name Domain LOTUS > Native Name CN=Gilles > Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1 > Foreign Native Name CN=Gilles > Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS/nEMEA1/n/n > Organization PHILIPS > Org Unit 1 RESEARCH > Org Unit 2 LIM > Last Name Delmas > First Name Gilles > > > > Status 769 > Explanation Invalid recipient > > X.400 Status 769 > Explanation Error delivering to SUR003M/M/SERVER/PHILIPS > mail5/gillesdelmas.nsf; File truncated - file may have been damaged

1 0

[QOS] New reject reasons in QOS proposal
by Rich Bowen 30 Jan '00

30 Jan '00

[Resending with the correct address for itu-sg16.] Mr. Roy, I'm working on the Rapporteur's TD that incorporates your QOS contributions from the Red Bank meeting as previously discussed and I have a question about the reject reasons related to QOS. APC 1668 indicates that "the rejectReason field of the ARJ message should also be extended to include the parameters related to the bandwidth and transportQOS." Currently the AdmissionRejectReason structure has a choice "requestDenied" that indicates, according to the comment in the ASN.1, that the requested bandwidth was not available. Also there is a choice "qosControlNotSupported" that appears to indicate that the GK concluded that either it or the endpoint did not have the QOS capabilities required to make the call. Do these two fields meet the requirements, or did you have something else in mind? Also, APC 1669 indicates that "the rejectReason field of the BRJ message should also be extended to include the parameters related to the transportQOS." The BandRejectReason structure currently defines a choice of "insufficientResources" that I assume is typically used to indicate that the requested bandwidth is unavailable. Were there additional details that you had in mind? Copying the itu-sg16 list since there may be other interested parties. Thanks, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC --------------------------------------------------------------------

1 0

MWIF
by Edgar Martinez [1] 30 Jan '00

30 Jan '00

Dear IPer's and Mobiler's, Mobile Wireless Internet Forum http://www.mwif.org/ The Mobile Wireless Internet Forum (MWIF) is an international non-profit industry association. Its mission is to drive an open internet-based architecture that enables seamless integration of mobile telephony and IP-based services (voice, data, video, web, etc.) for the mobile wireless networks and is independent of the air interface. Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Delayed contributions uploaded
by Gösta Linder (LME) 27 Jan '00

27 Jan '00

Mr. Okubo, Due to some technicalities I am not able to upload document to the FTP Incoming directory. Would it be propriate for you to upload the following LM Ericsson delayed contributions as attached? "Liaison with Tiphon on Mobility Management" <<Tiphon Liaison.zip>> "Refinement of Mobility Management Framework" <<Mob Mgmt Framework.zip>> Thanks in advance / Gösta Linder

2 1

Delayed Contribtions Uploaded to pictel site
by Michael Fortinsky 26 Jan '00

26 Jan '00

The following contributions have been uploaded to the pictel site: ftp://standard.pictel.com/avc-site/Incoming/ ftp://standard.pictel.com/avc-site/Incoming/ H225_AnnexG_Proposal_For_New_Version.zip Document Title: Proposal For New Version of the H.225.0 Annex G Standard ftp://standard.pictel.com/avc-site/Incoming/ H225_AnnexG_Service_Relationships_and_Usage_Specs.zip Document Title: H.225.0 Annex G - Specification and Negotiation of Usage Specifications During Service Establishment or Renewal Sincerely, Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Looking for the source of text in H.323 Implementers Guide
by Paul E. Jones 26 Jan '00

26 Jan '00

Folks, I am trying to find the author of some text that appears in the H.323-Series Implementers Guide approved in May 1999. The text in question is in section 6.3.4. The description of the problem in the IG is: ----- The Fast Connect procedure allows endpoints to determine certain capabilities of peer endpoints in the absence of the full disclosure provided by the H.245 capabilities exchange procedure. This should be reflected in H.245 section 7.2.1, (terminal capability messages) Overview and section 7.3.1, Open Logical Channel under the description of the dataType parameter, where the following text should be added. ----- The specific text that has been added is: ----- If an endpoint has not indicated non-null receive capabilities through a Terminal Capability Set message, capabilities not previously indicated by the endpoint may be contained in the dataType parameter. In this case, the receiving entity shall consider that the sending endpoint has the specified capabilities, and furthermore, simultaneous capabilities may be indicated by the dataType of any logical channels associated with this request through the use of the associatedSessionID parameter. ----- and ----- If an endpoint has not indicated non-null receive capabilities through a Terminal Capability Set message, capabilities not previously indicated by the endpoint may be contained in the dataType parameter of an Open Logical Channel message. In this case, the receiving entity shall consider that the sending endpoint has the specified capabilities, and furthermore, simultaneous capabilities may be indicated by the dataType of any logical channels associated with the Open Logical Channel request through the use of the associatedSessionID parameter. ----- If you are the author of this text, or if you can tell me the source of this text, please contact me. As far as I can tell, this text first appeared in TD-14 of the Monterey meeting in February 1999. Best Regards, Paul

1 0

Delayed Contributions are uploaded
by Orit Levin 26 Jan '00

26 Jan '00

Hello! The following Delayed Contributions are uploaded to the Incoming Directory: - "Robustness Procedure" in RV-Robustness.zip - "Improved H.245 Procedures" in RV-H245Procedures.zip Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: Delayed contributions uploaded
by Reddy, Paul K 26 Jan '00

26 Jan '00

Mr. Okubo and colleagues, Per your request, I have just uploaded my delayed H.323 SG16 contributions to the AVC site. (ftp://standard.pictel.com/avc-site/Incoming) The filenames are: 1. H_246_AnnexE_Geneva_02072000.doc 2. H323_MobilityDefn_Geneva_0207200.doc also I upload the above files as Zipped files: 1. H-246-Annex-E.zip 2. H323_MobilityDefn_Intel.zip Please review the enclosed documents and provide you comments to me. thanks a lot. regards, Paul Paul K. Reddy Intel Corporation Mailto:paul.k.reddy@intel.com Office Phone: +1.503.264.9896 Mobile Phone:+1.503.807.9564

1 0

Delayed contributions for H.323 Annex K
by Espen Skjæran (ETO) 26 Jan '00

26 Jan '00

Colleagues, I have uploaded two Ericsson contributions relating to H.323 Annex K to the pictel site: ftp://standard.pictel.com/avc-site/Incoming/ Draft_H323_annexK.zip The draft of H.323 Annex K proposed for determination H323_annexK_h2250changes.zip Modifications to H.225.0v4 to support it. There is not a lot of changes since Red Bank; - Added support for multiple service control sessions initiated on same signalling channel - Removed use of IRQ for ras signalling and instead added two new RAS messages, ServiceControlIndication and ServiceControlResponse Regards, Espen

1 0

Delayed Contribtions Uploaded to pictel site.
by Christian Groves 26 Jan '00

26 Jan '00

Hello, The following Ericsson contributions have been uploaded to the pictel site: ftp://standard.pictel.com/avc-site/Incoming/ delayed_ATMtransport.doc --- ATM transport for H248 delayed_new_work.doc --- Proposes new work items for SG16 delayed_SCTP_determination.doc --- SCTP transport for H248 delayed_signalsh248.doc --- Discusses signals in H248. Regards, Christian

1 0

Delayed Contribution Uploaded
by Nicolas Tran 26 Jan '00

26 Jan '00

Dear Mr. Okubo and colleagues, I have uploaded the following Delayed Contribution to the AVC site ( ftp://standard.pictel.com/avc-site/Incoming) DelayMTD-107C.zip : "H.323 Annex H (User, Terminal and Service) - Clear Split of functions between Call Control and (radio) Access networks" Best regards, Nicolas Tran. ALCATEL tel. +33 (0) 1 3077 1616 Email: Nicolas.Tran(a)alcatel.fr

1 0

Uploaded Delayed Contributions
by Tom-PT Taylor 26 Jan '00

26 Jan '00

I have uploaded the following Canadian Delayed Contributions to the Incoming directory: H323SIPProp.zip: "Interworking Between SIP and H.323 Networks" H248AASPkg.zip: "Proposal For An Advanced Audio Server Package For H.248" H.225GTRIPProp.zip: "Proposed Work Item: Interworking H.225.0 Annex G with TRIP" H323MClarif.zip: "Proposed H.323 Annex M related Coding Clarifications" H323LMotiv.zip: "Motivation for Three (3) Services Models" Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

3 2

Delayed contributions uploaded
by Rich Bowen 26 Jan '00

26 Jan '00

Mr. Okubo, I have uploaded the following Cisco delayed contributions to the Incoming directory: "Extensible Support for Dynamic Configuration in RAS", ftp://standard.pictel.com/avc-site/Incoming/dcfg_in_ras.zip. "Error in Published H.225.0 ASN.1", ftp://standard.pictel.com/avc-site/Incoming/asn1_mixup.zip. "Usage Information Reporting in RAS", ftp://standard.pictel.com/avc-site/Incoming/usage-info-contribution-v4.zip. Regards, Rich -- Richard Bowen Cisco Systems, Inc.

2 1

Delayed contribution from Japan
by Hidenobu Harasaki 26 Jan '00

26 Jan '00

Dear Q.12-14 experts, I have uploaded a delayed contribution on behalf of Japan National Body. ftp://standard.pictel.com/avc-site/Incoming/MPEG-4Delayed.zip The title is "H.225.0 packetization specification for ISO/IEC 14496-2 and ISO/IEC 14496-3". Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

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