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@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@mailbag.intel.com