Summary of MoIP reliable transport conference call
dduehren at BROOKTROUT.COM
Fri Jun 22 15:01:07 EDT 2001
Why do we get this after the "next conference call" is scheduled. Some
of would like to participate.
Vice President of R&D, CTO
dwd at brooktrout.com <mailto:dwd at brooktrout.com>
410 First Avenue
Needham, MA 02494
Tel: +1-781-433-9402 / Fax: +1-781-433-9202
> -----Original Message-----
> From: James_Renkel at 3com.com [mailto:James_Renkel at 3com.com]
> Sent: Friday, June 22, 2001 2:36 PM
> To: itu-sg16 at mailbag.cps.intel.com; tr301 at tiacomm.org;
> tsg16q11 at itu.int
> Subject: Summary of MoIP reliable transport conference call
> A conference call was held on Friday, June 15, 2001, between
> representatives of The CommWorks Corp. and Cisco Systems to begin
> discussing the requirements for a reliable transport protocol
> to be used
> with MoIP, the evaluations of existing protocols against
> those requirements,
> and the eventual recommendation of an exisitng (possibly
> modified) or new
> protocol for that purpose.
> On the call from The CommWorks Corp. were:
> - Mike Nicholas; and
> - Jim Renkel.
> From Cisco Systems were:
> - Herb Wildfeuer; and
> - Mehryar Garakani.
> The call began by discussing the events that led up to the
> call. It was
> agreed that the goal of this and future follow-on calls is to
> develop a
> joint CommWorks / Cisco Systems contribution to the next meeting of
> TR-30.1 giving requirements for the MoIP reliable transport mechanism
> that could be agreed to by the two companies, and possibly an
> of existing protocols against these requirements that both
> companies could
> also agree to. Requirements and evaluations that could not be
> agreed to by
> the two companies would be left for presentation by each
> company separately.
> It is understood that there is a desire, once the
> requirements and possible
> evaluations have been presented to TIA TR-30.1 and agreed to
> by them, to have
> the requirements and possible evaluations presented to the
> IETF 51 meeting
> in London, UK, during the week of 8/5/2001. It is also
> understood that some
> parties plan to present a draft protocol proposal to that meeting.
> It was then agreed that proprietary information previously
> disclosed in
> contributions to the ITU-T and TIA groups studying MoIP could
> be discussed
> in these conference calls, but no new proprietary information
> should be
> first disclosed in these calls.
> It was then suggested and agreed that a small "reference
> model" would be
> useful in the discussions. The following was agreed to as the
> refence model,
> subject to future modification as may be necessary:
> - The reliable transport issue is bi-directional and
> symmetric, but is
> perhaps best addressed by: considering the
> uni-directional, asymetric
> case; then combining the uni-directional case with a
> mirror image of
> itself to yield the bi-directional case.
> - The uni-directional case can be represented by this diagram:
> (See attached file: Reliable transport.vsd).
> Discussion then turned to CommWork's contribution PCM01-020,
> mechanisms in MoIP operations", to the Nice, FR, rapporteur's
> meeting of
> Q11/16, in particular a row by row discussion of Table 1, "Transport
> mechanism characteristics", on page 8 of that contribution.
> It was agreed that the transport protocol must support
> two-way, unicast
> sessions. It need not support one-way only or multicast
> sessions. Jim Renkel
> will draft requriements statements reflecting this for
> consideration for
> inclusion in the joint contribution .
> It was agreed that the protocol should be structure
> preserving, but that
> this should be described as "packet oriented rather than
> stream oriented."
> Mehryar Garakani will draft requirements statements
> reflecting this for
> consideration for inclusion in the joint contribution .
> In considering the next characteristic, "Structure format
> it was agreed that the issue really being considered here is that of
> switching / transitioning among VoIP, FoIP, and MoIP "modes"
> during the
> course of a call. While no firm agreement was reached on the
> and mechansim for doing this, the discussion seemed to
> indicate that the
> companies were close to agreement. Each company will draft
> for this to be exchanged via e-mail prior to and discussed at the next
> conference call.
> The next conference call is to be held Tuesday, 6/19/2001, at
> 10:30 A.M.,
> CDT, 8:30 A.M., PDT.
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