[Robustness] Minutes and telecon on May 9 11AM EST USA -- final r eminder

Maureen Stillman Maureen.Stillman at NOKIA.COM
Mon May 8 09:32:52 EDT 2000

The next robustness teleconference will be held on Tuesday, May 9 at 11AM

The phone number to call is:

Passcode: 2721#
You must enter the # sign after the passcode.


1.  We will discuss the tradeoffs of three different approaches to
robustness (discussed in minutes to appear by Monday - 5/8)
2. Next steps for Japan meeting

Minutes of H.323 Robustness Teleconference - May 4, 2000
Prepared by Maureen Stillman, Nokia

Next Teleconference: May 9, 2000 11AM EST USA

Present on the call:
Tim Chen, Mahesh Bhan & Archana Nehru - Trillium
Tim Sipsey - Aspect
Terry Anderson - Lucent
Randy Stewart - Motorola
Maureen Stillman - Nokia

        1.      Plans for Osaka
        2.      Continue discussion of technical options


There was a discussion of what messages can be lost at the H.323
(H.225/H.245) layer.

There are two ways to approach the problem of lost messages.  In Q.931 all
"application" messages are ACKed.  In H.323 (call control and call setup)
some end-to-end messages are ACKed and others are not.  One way of solving
this problem is to define end-to-end ACKs for all H.323 messages.

To make H.323 backwards compatible with earlier versions that would not
support this function, we would introduce a flag that would indicate that
this component supports end-to-end ACKs.  Another flag could indicate that
the component supported robustness mechanisms.  In this manner, we could
signal support for end-to-end ACKs but not other robustness mechanisms or
support for both.  The end-to-end ACKs would be mandatory for any component
that supports robustness mechanisms.

Trillium agreed to write up a submission on end-to-end ACKs for the Osaka

Given this discussion we identified three different ways to proceed for the
Osaka meeting:

        1.      Status Query mechanism without DDP

        The status query mechanism is the robustness procedure submitted to
the Geneva meeting.  This mechanism would be enhanced by support for the
end-to-end ACKs.  The gatekeepers would be required to recover state from
its upstream or downstream neighbors.

        2.      DDP with end-to-end ACK

        See Osaka submission APC1772 "On H.323 Robustness Architecture Using
DDP and SCTP".  The alternate Gatekeeper mechanism would be replaced by DDP.
DDP would serve two purposes, one to transparently select alternates and the
second to use a bulletin board or other mechanism to keep state consistent.
Bulletin board would not be the required mechanism as any other mechanism
used to checkpoint would be sufficient.

        3.      end-to-end ACK without DDP

        The end-to-end ACK mechanism would be supported.  We would make use
of the alternate Gatekeeper mechanism.  Any other mechanism for pooling and
checkpointing would be proprietary.

        At the next teleconference, we will discuss these three

-- maureen

Maureen Stillman
Member of Scientific Staff             Voice: (607)273-0724 x62
IP Voice Networks                       Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: maureen.stillman at nokia.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list