Definitions of terms for [Robustness]
Maureen.Stillman at NOKIA.COM
Mon Nov 22 09:09:23 EST 1999
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 at 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 at cisco.com
Paul Jones Paul.jones at ties.itu.int
Radhika Roy rrroy at att.com
Orit Levin orit at radvision.com
Terry Anderson tla at lucent.com
Kumar, Vineet vineet.kumar at intel.com
Michael Corrigan Michael_Corrigan at mw.3com.com
Robert Callaghan Robert.Callaghan at ICN.siemens.com
Glen Freundlich ggf at lucent.com
Boaz Michaely Boaz_Michaely at vocaltec.com
Jean-philippe Caradec caradec at piano.grenoble.hp.com
Maureen Stillman maureen.stillman at nokia.com
Yorg Ott jo at tzi.uni-bremen.de
Michael Vortensy at Vocaltech (please send me your e-mail address)
Ed Federmeyer Ed_Federmeyer at 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.
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.
The group formulated the following (incomplete) list of goals for the
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
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.
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.
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
Gatekeeper goes down or fails - the two endpoints lose the call signaling
We agree that such a call needs to be continued - how this should be done is
a problem that needs to be solved.
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 at nokia.com
More information about the sg16-avd