Subject: [AVT] VMR-WB RTP Payload and Storage Formats

From: [email-masked]
Date: Tue, 28 Sep 2004 10:21:02 -0700

Dear Colin,

It has been more than a month that an inconclusive discussion about RTP timestamp and separate MIME sub-types for VMR-WB has been going on that has definitely delayed the completion and publication of an RFC for VMR-WB.

Following this discussion, I now believe that your concern about the use of a single RTP clock rate of 16000 Hz for VMR-WB is not justified. 

We know that VMR-WB decoder can decode the payload content with NO regard to the encoder input sampling rate (8000 or 16000). By default, VMR-WB decoder outputs wideband speech. We also know that there are some people that would like to inject 8000 Hz media and still want to be able to decode the bit stream without having to tamper with the RTP timestamp. 

The selection of the sampling rate of the decoder output media (8000 or 16000 Hz) depends on the receiving platform hardware audio/acoustic capabilities and is NOT of concern for the RTP payload design.

The use of a single RTP clock rate of 16000 would technically cause NO harm and it can further satisfy people who wish to inject narrowband media. It does not create interoperability problems in the network. It is not a departure from RTP traditions, since VMR-WB in the first place is a wideband speech codec with 16000 Hz sampled audio input/output.

On the issue of separate MIME sub-types for the payload and storage as Magnus proposed, I fully agree with you that it is not a good idea and fragments the MIME name space. This would be a clear departure from previous conventions that I am not comfortable with.

We need to move forward. I would like to submit a revised draft for Working Group Last Call by the end of the week with the following changes:

1- Addressing Magnus' editorial changes.
2- Using a single RTP timestamp of 16000 Hz with appropriate clarifications.
3- I will not separate MIME sub-types, only will allow the use of MIME parameters "mode-set" and "channels" for the storage format.

Your understanding and consideration are appreciated in advance.

Regards

-Sassan Ahmadi

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