Subject: AW: [AVT] updated "Clearmode" (64kbit/s unrestricted) Internet-dr aft

From: Kreuter Ruediger <[email-masked]>
Date: Tue, 11 Mar 2003 16:01:43 +0100

Hi Magnus,

thanks for your indepth review and the according comments.
They are still true for version 02, so the updates will 
come in version 03 after the upcoming IETF Meeting.

See more detailed answers below.

Regards,
Rüdiger Kreuter
Siemens AG
ICN CP Systems Engineering
D-81359 München
Tel    +49 89 722 62553
Fax    +49 89 722 130 62553
[email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund [mailto:[email-masked]]
> Gesendet: Donnerstag, 6. März 2003 16:28
> 
...
> 
> 1. Chapter 2: First sentence seems strange it looks like it lacks 
> context. "The profile .." refers to something which I don't 
> know what it 
> is.

This will be changed to "This document .." in version 03.

> 
> 2. Maybe a little more text on how data is put in the payload format. 
> Especially around the number of samples you are allowed to 
> put into each 
> packet.

Well, this chapter was copied and adapted from the PCMA/PCMU
section of draft-ietf-avt-profile-new-12.txt, because the
CLEARMODE handling is similar (simple).

I will add some of the generic payload handling descriptions of
draft-ietf-avt-profile-new-13.txt, which are relevant for
CLEARMODE too.

As PCMA/PCMU the number of samples just depends on the supported 
packet sizes, since CLEARMODE is sample oriented.

> 
> 3. End of chapter 2: "The timestamp SHALL be set according [5]"
> Shouldn't this be "The timestamp SHALL be set according to [5]."

O.k. this will be changed in version 03

> 
> 4. Chapter 3: Optional parameters. I think "maxptime" is a 
> valid one to 
> use. The existing RFC with this parameter is RFC 3267 but the updated 
> SDP draft also contains a definition of it.

Accepted, this will be added in version 03:
*******************************************
Optional parameters: ptime, maxptime
"ptime" gives the length of time in milliseconds represented 
by the media in a packet [7].
"maxptime" represents the maximum amount of media which can be 
encapsulated in each packet, expressed as time in milliseconds [10].
*******************************************

... where [10] is a new reference to:
M. Handley, V. Jacobson and C. Perkins, "SDP: Session Description 
Protocol", revision of 2327, work in progress.

> 
> 5. Chapter 3 is missing rules on how you apply the mime parameters to 
> SDP. Please see draft-ietf-avt-rtp-mime-06.txt for such a chapter.

A new chapter will be added in version 03:
******************************************
4. Mapping to SDP parameters

Parameters are mapped to SDP [7] in a standard way.
o  The MIME type (audio) goes in SDP "m=" as the media name.
o  The MIME subtype (CLEARMODE) goes in SDP "a=rtpmap"
   as the encoding name.
o  The optional parameters "ptime" and "maxptime" go in the 
   SDP "a=ptime" and "a=maxptime" attributes, respectively.

An example mapping is as follows:

        audio/CLEARMODE; ptime=10

        m=audio 12345 RTP/AVP 97
        a=rtpmap:97 CLEARMODE/8000
        a=ptime:10

Note that the payload format (encoding) names defined in the 
RTP Profile are commonly shown in upper case.  MIME subtypes 
are commonly shown in lower case.  These names are case-
insensitive in both places.
Similarly, parameter names are case-insensitive both in MIME 
types and in the default mapping to the SDP a=fmtp attribute.
******************************************

> 
> 6. Reference list in chapter 5. Shouldn't there be nice [] around the 
> numbers?

They will be added in version 03 :-)

> 
> 7. Time to read the ID nits. You are lacking a couple of necessary 
> sections, like Copyright statement and IPR statement. See 
> http://www.ietf.org/ID-nits.html

Copyright and IPR statement will be added in version 03.
I didn't find other missing chapters.

> 
> 8. When you don't transport ISDN 7 kHz voice in this and 
> actually carry 
> some other type of data. Isn't of interest to mention RTP relevant 
> mechanisms to protect the stream against packet loss. There should be 
> significant considerations of this problem.

Since the application that uses Clearmode is unknown, it is 
hard to require an adequate method for packet loss concealment. 
So IMHO this is application dependent and therefore must be 
dealt with by methods outside the scope of this document. 

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