Subject: [AVT] I-D ACTION:draft-ietf-avt-variable-rate-audio-00.txt

From: [email-masked]
Date: Wed, 20 Oct 2004 10:25:38 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Timestamp Frequency for Variable Rate Audio Codecs
	Author(s)	: S. Wenger, C. Perkins
	Filename	: draft-ietf-avt-variable-rate-audio-00.txt
	Pages		: 6
	Date		: 2004-10-19
	
This memo discusses the problems of audio codecs with variable 
   external sampling rates.  Historically, for audio codecs, the RTP 
   timestamp frequency was chosen to match the sampling rate of the 
   audio codec.  However, this choice is nowadays more difficult to 
   justify, because of the advent of audio codecs (and, even more 
   important, practical use cases) that support multiple sample rates 
   and the switch between the sample rates during the lifetime of an 
   RTP session.  This Internet draft addresses the problem by 
   suggesting that RTP Payload RFCs for such codecs to utilize a 
   single, high, unified RTP timestamp frequency.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-variable-rate-audio-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Oct 2004 15:39:28 -0500

Hi, Stephan/Colin,

I like this solution and the draft summaries the issue/benefits very well.

...
>   *  Is it a good idea to require ALL future I-Ds on audio (not only
>      the variable clock frequency ones) to use the uRTR?
>   *  Or only those that do not fit the uRTR (fit == subset of prime
>      factors)?
...

Or, we can make uRTR a standard _option_ to all payloads - e.g., whenever rate param is set
to 192kHz (or whatever value we end up with), it would mean that uRTR is in use, if rate is
set to any other value, it implies that the actual sampling rate is in use.

regards,
-Qiaobing

[email-masked] wrote:

> ------------------------------------------------------------------------
>

---

From: "Stephan Wenger" <[email-masked]>
Date: Fri, 22 Oct 2004 23:46:47 +0300

Hi Qiaobing Xie,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Qiaobing Xie

> I like this solution and the draft summaries the issue/benefits very well.

Thanks for the flowers :-)

> Or, we can make uRTR a standard _option_ to all payloads - e.g., whenever
> rate param is set to 192kHz (or whatever value we end up with), it would 
> mean that uRTR is in use, if rate is set to any other value, it implies
> that the actual sampling rate is in use.

I don't like optional mechanisms very much -- they are not good for
interoperability, and increase the implementation burden.

Also, what would you do as a receiver if you get a-law with 192 kHz signaled
sample rate -- use 8 kHz (which would be the common use of a-law) or 192 kHz
(which would be a perfectly legal use case as well)?

Stephan

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 22 Oct 2004 17:01:27 -0500

Hi, Stephan,

Stephan Wenger wrote:
...
> interoperability, and increase the implementation burden.

Of cause, you don't have to call it "optional" ;-)

> (which would be a perfectly legal use case as well)?

Well, I am thinking that individual payload formats will be allowed to decide whether or not 
to support uRTR when they are defined. For instance, if the payload format is being defined 
for a-law, the RFC could say "uRTR is not supported" since it would not add any value to it. 
In such a case, signaling 192 kHz to the receiver would be an error. On the other hand, when 
a codec considers variable rate operation an integral part of its capability (e.g., vmr-wb, 
amr-wb+), the corresponding payload specs could then explicitly say "uRTR SHOULD be supported."

regards,
-Qiaobing