The minutes from the last robustness telecon held on December 14, 1999 are attached.
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@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@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@cisco.com Paul Jones Paul.jones@ties.itu.int Orit Levin orit@radvision.com Kumar, Vineet 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 (please send me your e-mail address)
Unable to attend, but submitted scenarios:
Radhika Roy rrroy@att.com
Submissions for the teleconference:
Radvision AT&T 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.
Discussion:
Scenario:
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 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. 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 safe".
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 call?
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@nokia.com www.nokia.com