asn1 out of standards ?

[Michael Stini]

The fourth in a series of conference calls to discuss a reliable transport
protocol to be used with MoIP was held on Friday, June 22, 2001.

As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these
conference calls is to develop a joint contribution to the next meeting of
TR-30.1 giving requirements for the MoIP reliable transport mechanism, and
possibly an evaluation of existing protocols against those requirements.
Once the requirements and possible evaluations have been presented to TIA
TR-30.1 and agreed to by them, the requirements and possible evaluations
are, if possible, to bepresented to the IETF 51 meeting in London, UK,
during the week of 8/5/2001. Some parties may present a draft protocol
proposal to that meeting.

On the call from The CommWorks Corp. were:
-    Fred Lucas; and
-    Jim Renkel.

>From Cisco Systems were:
-    Herb Wildfeuer; and
-    Mehryar Garakani.

>From Brooktrout was:
-    Dave Duehren.

The call began by discussing the proposed summary of the third conference
call. Cisco asked that the "background paragraph" from the first conference
call summary be added to this and all future conference call summaries. With
that addition, the meeting summary was agreed to and approved. After
making that addition, Jim will send the meeting summary to relevant e-mail
reflectors.

Next, it was agreed that draft conference call summarries would be sent
immediately to the e-mail reflectors, then reviewed, ammended if necessary,
and approved at the next conference call. That procedure is to start with the
summary of this conference call [which is this e-mail.].

Then, the next two conference calls were scheduled, as follows:
-    Friday, 06/29/2001, 10:30 A.M., CDT
-    Friday, 07/06/2001, 10:30 A.M., CDT
The dial-in arrangements for the conference calls would be the same as for
this conference call: access number +1.847.262.0999; conference ID "06647"
(That's "0MOIP" (zero-em-oh-eye-pea) on your touch-tome keypad.). [If you
plan to participate in these conference calls, please inform Jim Renkel
ASAP at James_Renkel at 3Com.com so that sufficient conference bridge ports
can be arranged.]

Next, the CommWorks proposed language for media stream / protocol stack
switching was discussed. It was agreed that, while interesting in general
and perhaps impacting the reliable transport protocol, this really is
material for annexes to V.moip and relevant signaling channel protocol
specifications.

Then, the meeting returned to Table 1 of CommWork's PCM01-020 contribution
to the Nice, FR, rapporteur's meeting. It was agreed that the forward error
correction characteristic should, at most, be an optional capability of the
reliable transport protocol and that its use must be negotiated on a
session-by-session basis.

It was then agreed that forward error correction was but a means, perhaps
with other characteristics or requirements, to the end of low latency. It
was agreed that low latency, however achieved, was a desirable characteristic
of the reliable transport mechanism. Mehryar will draft requirement language
to this effect.

In this vein, it was then agreed, in considering requirements for a reliable
transport protocol, to concentrate first on "high-level" requirements or basic
capabilities, such as low latency, and then on "low-level" requirements or
enhancements, such as forward error correction. When that consideration is
complete, all requirements would be prioritized in some way TBD.

It was agreed that forward error correction and error correction by continuous
transmission should be relegated to the low-level or enhancements category.
Agreement could NOT be reached on whether error correction by retransmission
should also be relegated, or be placed in the high-level or basic capabilities
category.

Finally, it was agreed that rather than continue enumerating capabilities,
characteristics, requirements, etc., we would next consider deficiencies,
if any, in known protocols that would prevent them from being used for MoIP
and FoIP, or make their use less than ideal.

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