RE: [AVT] Re: Clearmode definition.
Rajesh Kumar <rkumar@cisco.com> Tue, 23 March 2004 08:32 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11351 for <avt-archive@odin.ietf.org>; Tue, 23 Mar 2004 03:32:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hKU-0003YY-Ap for avt-archive@odin.ietf.org; Tue, 23 Mar 2004 03:32:11 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N8WAw3013669 for avt-archive@odin.ietf.org; Tue, 23 Mar 2004 03:32:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5hKM-0003X7-Hi; Tue, 23 Mar 2004 03:32:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gW3-00073d-BY for avt@optimus.ietf.org; Tue, 23 Mar 2004 02:40:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09626 for <avt@ietf.org>; Tue, 23 Mar 2004 02:40:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gVz-00052N-00 for avt@ietf.org; Tue, 23 Mar 2004 02:39:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gV1-0004wZ-00 for avt@ietf.org; Tue, 23 Mar 2004 02:39:00 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5gUA-0004kI-00 for avt@ietf.org; Tue, 23 Mar 2004 02:38:06 -0500
Received: from rkumar-w2k01.cisco.com (sjc-vpn1-1021.cisco.com [10.21.99.253]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2N7bWQK021113; Mon, 22 Mar 2004 23:37:32 -0800 (PST)
Message-Id: <4.3.2.7.2.20040322233426.01cc3a50@vtg-um-e2k1.cisco.com>
X-Sender: rkumar@vtg-um-e2k1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Mar 2004 23:37:31 -0800
To: Yaakov Stein <yaakov_s@rad.com>
From: Rajesh Kumar <rkumar@cisco.com>
Subject: RE: [AVT] Re: Clearmode definition.
Cc: Colin Perkins <csp@csperkins.org>, avt@ietf.org
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52024E9B9A@exrad2.ad.rad.co. il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Yaakov, One of the cases you mention include an RTP encapsulation of Nx64. Unless you have already done so, I recommend you register a MIME for it and allow its session-by-session negotiation using SDP, H.245 or other means. My guess from having read the PWE3 drafts in the past is that you are limiting the application to a provisioned RTP Nx64 session. While that is adequate in some applications, others will require/prefer the signaled establishment of Nx64 sessions. Best regards, Rajesh At 05:13 PM 3/21/2004 +0200, Yaakov Stein wrote: > > > --> Rajesh Kumar <rkumar@cisco.com> writes: > > > Are there plans to address N x 64 clear mode (N > 1) in > > > draft-ietf-avt-rtp-clearmode-04.txt ? > > > > > > One method might be to have N as a MIME parameter. > > > > > > I recommend that we do. > > > > No. This is explicitly out of scope of AVT, and will be > > addressed in the PWE3 working group. > >N*DS0 (i.e. N 64Kbps timeslots) with or without CAS >is defined in the PWE3 TDM requirements draft as a structured TDM >service. > >Right now in PWE we have three TDM drafts: > >1) The standards track one is SAToP (Structure Agnostic TDM over >Packet), >but this only handles full T1, E1, E3 or T3 trunks >(whether structured or not). Thus this doesn't address N*64. > >2) CESoPSN - candidiate informational RFC >This draft can handle N*DS0 by encapsulating one or more frames or N >timeslots >per packet, with or without RTP. > >3) TDMoIP - candidate informational RFC >This draft can handle N*DS0 by using AAL1 which appends >pointers to identify the first timeslot. >If the 64K channels are carrying HDLC data, there is a mode >which suppresses idle flags. > >As you can see, the treatment of N*DS0 is only in the informational >drafts, >not in the standards track one. > >The current suggestion for communicating N is via the PWE control >protocol, >where there is a parameter called CEP/TDM bit rate. > >Y(J)S _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] RE: Clearmode definition. Kreuter Ruediger
- RE: [AVT] Re: Clearmode definition. Yaakov Stein
- RE: [AVT] Re: Clearmode definition. Rajesh Kumar
- RE: [AVT] Re: Clearmode definition. Yaakov Stein
- RE: [AVT] Re: Clearmode definition. Rajesh Kumar
- Re: [AVT] Re: Clearmode definition. Colin Perkins
- Re: [AVT] Re: Clearmode definition. Colin Perkins
- Re: [AVT] Re: Clearmode definition. Colin Perkins
- Re: [AVT] Re: Clearmode definition. Rajesh Kumar
- Re: [AVT] Re: Clearmode definition. Colin Perkins
- Re: [AVT] Re: Clearmode definition. Christian Groves