Minutes of H.323 Robustness Teleconference - November 17, 1999 Prepared by Maureen Stillman, Nokia
Next Teleconference: Will be held on Tuesday, December 14 at 11AM EST USA. Nokia will host this again. Please send e-mail to maureen.stillman@nokia.com if you wish to join in.
Agenda for the next teleconference:
Discuss failure scenarios that have been posted to the mailing list by the robustness working group.
Action items from this teleconference:
1. Post meeting minutes to mailing list
2. Post terms and definitions from submission D.225 Santiago Chile from R. Roy of AT&T to mailing list to kick off a discussion of terms.
3. Everyone needs to post to the SG16 mailing list one or more failure scenarios that require robustness/recovery mechanisms. Please complete this by December 6 and include in the subject heading the keyword [Robustness]. Anyone is welcome to send a scenario, so please join in.
Attending the 11/16 teleconference:
Rich Bowen rkbowen@cisco.com Paul Jones Paul.jones@ties.itu.int Radhika Roy rrroy@att.com Orit Levin orit@radvision.com Terry Anderson tla@lucent.com Kumar, Vineet vineet.kumar@intel.com Michael Corrigan Michael_Corrigan@mw.3com.com Robert Callaghan Robert.Callaghan@ICN.siemens.com Glen Freundlich ggf@lucent.com Boaz Michaely Boaz_Michaely@vocaltec.com Jean-philippe Caradec caradec@piano.grenoble.hp.com Maureen Stillman maureen.stillman@nokia.com Yorg Ott jo@tzi.uni-bremen.de Michael Vortensy at Vocaltech (please send me your e-mail address) Ed Federmeyer Ed_Federmeyer@mw.3com.com Sasha Ruditsky at Radvision (please send me your e-mail address)
Summary of Teleconference:
Robert Callaghan reported that the direction of the rapporteurs from Study Group 16 was that the robustness working group produce a submission that could be debated and voted on at the February meeting in Geneva. Given this deadline, the group decided on the following course of action:
Step 1: Describe scenarios to determine which failures exist (see action item number 3).
Step 2: Examine scenarios and determine means to deal with them
Step 3: Determine short term measures for dealing with failures and propose them at the Geneva meeting.
Discussion:
Definition of terms for robustness: We need to define terms. This was supposed to happen on the mailing list over the last month, but no one sent any input. It was suggested that we use R. Roy's definitions in section 2 of D.225 as a starting point for the discussion. These definitions will be posted to the mailing list (see action item 2).
Short Term Issue #1: The problem of defining the alternate gatekeeper mechanism is not quite solved. Some of problems with it in the H.323 document were brought up at the Red Bank meeting.
Short Term Issue #2: The standard's document does not adequately describe whether we are referring to a TCP connection or a call signaling channel. What is the difference between a disconnect versus an IP failure? We need to carefully go through the standard and clarify in each place clarify what precisely is meant by "call signaling channel".
Short Term Issue #3: For systems currently compliant with H.323 v3 or lower, if a call is disrupted the endpoint is left in a "hung" state, meaning that you can't make another call to the endpoint and you can't recover. It was suggested that we deallocate or clear the resources associated with these "hung" calls so that the endpoint can receive new calls and operate normally again. The group decided that we need to perform further analysis before we decide on how to deal with this issue.
Goals:
The group formulated the following (incomplete) list of goals for the robustness work:
1) Recovery from GK crash 2) Recovery from other components crashing including gateways, MCUs, MGC, etc. 3) GW switching NIC cards during a call 4) Call signaling channel fails; but we don't want to lose a call already in progress between two endpoints. 5) How do you detect a failure? 6) What are the procedures for recovery from a failure? 7) Clarify on how to reestablish call signaling
Legacy Issue: Once we have decided on robustness mechanisms, these would be included in version 4 or later of the standard. How do we deal with earlier versions of H.323 that don't handle robustness? How do we deal with the fact that in an operational system some components will support robustness mechanisms and some will not?
Call Signaling Channel Issue:
Standard currently says that the call signaling channel can be closed during a call and the call will continue. It also states that the call signaling channel can be reopened, but it doesn't say how. The problem is that we don't know how to associate the new connection with any ongoing call. A second problem is that we may need the call signaling channel to establish supplementary services. If the channel has been closed, then we may want to bring it back up for supplementary services.
Scenarios:
It was decided that the work of the robustness group should be scenario driven. We need to determine what failure scenarios are likely to occur in order to understand how to correct them. It was decided that everyone from the group would submit one or more scenarios in time for the next teleconference for discussion (see action item 3). Please submit these to the list by December 6.
Simple Scenario:
We discussed the most simple and basic scenario (outlined by Y. Ott):
Corporate Environment - 1 gatekeeper; all calls are gatekeeper routed; H.225 up and running; might be using fastconnect; two endpoints have a call in progress
Gatekeeper 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.
-- 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