This is a final reminder that we will be having the first teleconference on robustness sponsored by Nokia on Tuesday, November 16 at 11AM EST USA.
The phone number to call is:
613-688-2795 and the access code is 1097#. You must enter the pound key after the access code.
The tentative agenda is:
Definitions of Terms for robustness Items that can be settled in the short term
Additional agenda items from the mailing list:
They are topics we should discuss during the phone call or decide to defer. I took most of this text directly from your e-mail messages....
Summary of Agenda Items from the mailing list:
1) contribution D.225 - "Framework for Reliable H.323 Gatekeeper Architectures" How will this contribution be added and referenced in the "terms of reference" Red Bank document TD-028?
2) Further discussion of the proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel while a call is still in progress.
3) Recovery from GK crash
4) The more difficult problem is that upon TCP channel failure, the TPKT connection gets out of synch. It means that the application layer doesn't know automatically what part of information got lost. In this case, in order to synchronize H.323 Call state between the two sides, application level handshake must be introduced. This is also definitely a job for our Robustness group.
5) Another issue we have at hand is that of "what is a call signaling channel?" There used to be a one to one mapping between TCP connections and call signaling channels. This is not the case any longer-- one may have multiple calls over the same call signaling channel and one may not even use TCP. Making this distinction will be important for the robustness work being started, as the "logical" connection (the call signaling channel) and the "physical" connection (the TCP or UDP connection) must be referred to independently. (I'm quite open to new terms for here...). It is important to recognize whether an endpoint has closed the call signaling channel (as we understand it today) or if the physical connection has failed. Since we do not signal that we are going to close the call signaling channel today-- we just close the socket-- it makes this problem more difficult.
6) Actually, the SCTP transport protocol defined by Sigtran is specifically designed to address the path level robustness. It is designed to support multiple NIC cards (a.k.a. multi-homed nodes) and provide transparent interface and path failure detection and recovery.
7) think that Sigtran could be used to provide the GK "switch over" to a hot standby GK from the IP layer point of view.
Conference Call Participants (so far): all are welcome to join in!
Rich Bowen rkbowen@cisco.com Roy Radhika rrroy@att.com Orit Levin orit@radvision.com Dave Walker dave_walker@Mitel.com Terry Anderson tla@lucent.com Kumar, Vineet vineet.kumar@intel.com Asaf Steifeld AsafS@radware.co.il Michael Corrigan Michael_Corrigan@mw.3com.com Robert Callaghan Robert.Callaghan@siemenscom.com Glen Freundlich ggf@lucent.com Boaz Michaely Boaz_Michaely@vocaltec.com Jean-philippe Caradec caradec@piano.grenoble.hp.com
Talk to you Tuesday....
-- 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