APC-1866 uploaded

[Jill Caugherty]

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

The phone number to call is:

(613)688-2795
Passcode: 2721#
You must enter the # sign after the passcode.

Agenda:

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

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

Discussion:

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

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







-- 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
www.nokia.com

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