Subject: [AVT] RE: Clearmode definition.

From: Kreuter Ruediger <[email-masked]>
Date: Fri, 19 Mar 2004 12:48:55 +0100

I introduced Nx64kbit/s into one of the early
versions of the Clearmode draft, to open a 
discussion about this issue (after an according
request in the AVT mailing list).
In response we had a discussion about this issue
in AVT and PWE3 and finaly decided to reduce
the Clearmode draft to 1X64kbit/s - for several
reasons.

1)
There were several drafts to this time 
dealing with Nx64kbit/s and PWE3 was in the 
process to harmonize them into one. We didn't 
want to come up with an additional approach.

2)
Just introducing a parameter N for Nx64kbit/s
is not enough. For N>1 you must describe how
the channels are packed in the RTP packet.
And there are several alternatives.
Additionally other information is needed.

There was a controverse discussion in PWE3
which leaded to reason
3)
When we discussed this issue with PWE3, it
became clear that the Nx64kbit/s would need
much more time to finish then a pure
Clearmode draft and we wanted to speed up
the MIME type registration for Clearmode.

So I agree with Colin, that we leave Nx64kbit
the the PWE3 group.

Regards, Ruediger

> -----Original Message-----
> From: Rajesh Kumar [mailto:[email-masked]] 
> Sent: Thursday, March 18, 2004 9:18 PM
> To: Colin Perkins
> Cc: Kreuter Ruediger; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Clearmode definition.
> 
> 
> At 08:12 PM 3/18/2004 +0000, Colin Perkins wrote:
> >--> Rajesh Kumar <[email-masked]> 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.
> 
> I do not understand why 64 kbps clearmode is any different 
> from 384 kbps. 
> Both can be negotiated codecs for a session type. N x 64 should be 
> negotiable session by session and not just relegated to the 
> provisioned 
> tunnel category. I recommend a MIME definition for it if you 
> do not want to 
> fold it into the MIME for 64 kbps clear mode, although I 
> would prefer the 
> latter.
> 
> 
> 
> >--
> >Colin Perkins
> >http://csperkins.org/
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 21 Mar 2004 17:13:31 +0200

> 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

---

From: Rajesh Kumar <[email-masked]>
Date: Mon, 22 Mar 2004 23:37:31 -0800

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