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@cisco.com Jill Caugherty jcaugher@cisco.com Jean-François Mulé jfm@clarent.com Vineet Kumar vineet.kumar@intel.com Robert Callaghan Robert.Callaghan@ICN.siemens.com Maureen Stillman maureen.stillman@nokia.com Jorg Ott jo@tzi.uni-bremen.de Michael Fortinsky Michael_Fortinsky@vocaltec.com Sasha Ruditsky at Radvision Roy Radhika rrroy@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@nokia.com www.nokia.com