[Robustness] minutes and next Telecon -- January 6 at 11AM EST US A

Maureen Stillman Maureen.Stillman at NOKIA.COM
Mon Jan 3 18:28:24 EST 2000

The minutes from the last robustness telecon held on December 14, 1999 are

The next conference call for robustness, arranged by Nokia, is scheduled for
Thursday, January 6th at 11:00 AM EST USA.

Agenda for the teleconference:

Discuss draft submission to SG-16 Geneva meeting written by Radvision
incorporating discussions from the last several robustness teleconferences.
The goal is to submit this input to the meeting by the deadline of January
27, 2000.  Radvision will post this draft to the mailing list prior to the
teleconference for our review.

Conference call number: 613-688-2795

The access code 5767#.  You must enter the pound sign after the access code.

Please send e-mail to maureen.stillman at nokia.com if you plan to attend.
Hope to talk with you on Thursday.

Minutes of H.323 Robustness Teleconference - December 14, 1999
Prepared by Maureen Stillman, Nokia

Next Teleconference:  Will be held on Thursday, January 6 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 draft submission to SG-16 Geneva meeting written by Radvision
incorporating discussions from the last several robustness teleconferences.
The goal is to submit this input to the meeting by the deadline of January
27, 2000.

Action items from this teleconference:

        1.      Post meeting minutes to mailing list

        2.      Radvision to post draft submission to the mailing list
before the Jan. 6 teleconference.

        3.      Everyone needs read the draft submission so we can discuss
it during the teleconference.

Attending the 11/16 teleconference:

Rich Bowen  rkbowen at cisco.com
Paul Jones Paul.jones at ties.itu.int
Orit Levin orit at radvision.com
Kumar, Vineet 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 (please send me your e-mail address)

Unable to attend, but submitted scenarios:

Radhika Roy rrroy at att.com

Submissions for the teleconference:

Nokia, Security and Robustness

Summary of Teleconference:

Given that submissions for the SG-16 Geneva meeting are due on January 27,
we decided to discuss short to medium term robustness solutions.  At the
Geneva meeting, we have the potential to add robustness solutions to the
draft of H.323 version 4.  Radvision agreed to draft a submission for
comment and debate at our next teleconference scheduled for January 6.  The
intent is to submit a technical contribution on robustness by the January
27th deadline.



We are focusing on the following scenario:

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.  We have a redundant GK that we want to
use.  How can we recover the call from this scenario?

If no component has any robustness mechanisms then the TCP connection should
be terminated by the endpoint.

Otherwise, if robustness mechanism is in place, we should base the solution
on that fact that both endpoints as well as the gatekeeper are robust aware.
The redundant gatekeeper starts the robustness procedure and will open new
TCP ports.  The endpoints will understand this based on the CALL ID value
(see discussion on CALL ID below).

On keeping the state of the call:

We need to transmit the call state between the GK and endpoint.  Should we
keep all messages or some messages?  Last transaction?

H.450 is designed to be "fail safe" meaning that in the event of a problem,
the service can fail but the call will not fail.

We can't assume that we can restore the "exact state" of the call because
unfortunately this is not deterministic.  We should ignore the case in which
someone is pushing keypad buttons, by assuming that they will just push the
buttons again if they don't get the right response.

We need a set of deterministic rules to determine what happens when there is
a failure so we can reconstruct the call state.  There will be a proposed
procedure to do this.  "Special protocols" such as H.450 must be "fail

H.225 has a status message.  What happens with H.245 that doesn't have the
equivalent of a status message?  The standard currently states that if H.245
is lost then the call is terminated.  We need to define extensions to H.245
to support ruggedness.

Discussion of Call IDs:

We need to determine what ID/IDs will be used for recovered calls.  For
example, will the conference ID or the call ID remain the same or will it be
different for the recovered call?  Will I get billed twice for the same

There are potentially two different cases:

        1.      Maintain the same call by using the same Call ID

        2.      Clear resources and have a new call with a new Call ID

Robert Callahan reported that there is currently an ad hoc group in Study
Group 16, which is discussing additional IDs associated with a call for
various purposes including billing.  They are talking about adding IDs for
billing supplementary services, for example.

The conclusion was that we should wait for this group to propose their
solution before deciding how CALL IDs for robustness should fit in.

Pros and Cons of Application Layer Restart:

Suppose we decide to design a restart mechanism that involves the endpoints.
Application layer restart is OK for the endpoint that knows that there has
been a failure, but what about an endpoint that doesn't know?  How does it
distinguish between a new call coming in and a call that is being restarted?

What if both endpoints determine that there is a problem and both decide to
restart the call?

**** end of minutes ****************

-- 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

More information about the sg16-avd mailing list