[Robustness] Minutes for the robustness telecon -- January 6, 200 0

[Maureen Stillman]

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