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

From: Scribano Gino-QA1087 <[email-masked]>
Date: Mon, 4 Oct 2004 23:58:24 -0500

Colin,

It seems that the 'sampling rate' issue has now crossed over to the Storage Format thread. In any case, it's been a while since my initial comments regarding application impacts of restricting the RTP timestamp to be equivalent to the source media sampling rate. So, I would like to reiterate that the impact of this restriction extends well beyond saving a few bytes of storage in a tone generation box. As I stated previously, this restriction is also problematic for mixing and/or switching diverse media sources in streaming and conversational applications.

Consider a conference bridging application, where at least one party is a land-line circuit (which requires 8 KHz sampling) and at least one other party is a wideband VMR-WB terminal (which may employ 16 KHz sampling). Conference bridging for these media streams requires switching and/or mixing the input streams into like output streams. According to your restricted method, use of the VMR-WB sample rate adaptation function for this application requires end-to-end session renegotiation (eg, an SDP offer-answer cycle for each leg) in order to achieve a common sampling rate, and hence timestamp interval, for all RTP terminations involved in the conference bridge. Additional latencies and synchronization complexities associated with end-to-end renegotiation of the sampling rate for all RTP terminations should not be required to establish and maintain the bridge in such applications.

Regards,
Gino

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: Monday, October 04, 2004 2:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [AVT] Re: VMR-WB RTP Payload and Storage Formats

Sassan,

I am likewise getting frustrated with the situation. However, I don't 
believe the arguments in favour of making the VMR-WB payload format 
inconsistent with other speech payload formats are compelling. The 
codec is not particularly special in its behaviour, and the argument 
that one wishes to inject 8 kHz sampled tones rather than injecting 
tones at native rate (i.e. you wish to save a few bytes of storage in 
the tone generation box) does not justify the inconsistency.

I regard a consistent and stable timing model across payload formats to 
be fundamental to the utility of RTP. You are trying to disrupt that 
for a trivial cost saving in a particular application. That is not an 
appropriate trade-off.

Colin

On 4 Oct 2004, at 19:08, <[email-masked]> wrote:

> Dear Colin,
>
> I am getting frustrated with the situation regarding the VMR-WB I-D.
>
> When this I-D was about to be accepted for the WGLC, a comment on the
> relationship between the sampling rate and RTP clock rate has put this 
> I-D in an ambiguous status.
>
> In the one hand, based on the distinctive capability of VMR-WB, there
> are people who want to use a fixed RTP clock rate of 16000 Hz to 
> enable processing/injection of the 8000 Hz sampled media. Note that 
> 8000 and 16000 Hz sampled media have identical VMR-WB output frames. I 
> believe there is technically nothing wrong and revision -04 of the I-D 
> appropriately addresses this concern.
>
> On the other hand, you persist on your opinion that RTP clock rate
> must be identical to the input media sampling rate regardless of the 
> codec capabilities.
>
> The following excerpt from Section 4.1 of RFC 3551 (line 434)
>
> "...
>    The RTP clock rate used for generating the RTP timestamp is
>    independent of the number of channels and the encoding; it usually
>    equals the number of sampling periods per second.  For N-channel
>    encodings, each sampling period (say, 1/8,000 of a second) generates
>    N samples.  (This terminology is standard, but somewhat confusing,
> as
>    the total number of samples generated per second is then the 
> sampling
>    rate times the channel count.)
> ..."
>
> indicates that (there is no normative language here) the RTP clock
> rate "usually" equals the input media sampling rate and that it is 
> independent of the encoding.
>
> Also the following excerpt from Section 6.4.4 of RFC 3550 (line 2391)
>
> "...
>    Since that timestamp is
>    independent of the clock rate for the data encoding, it is possible
>    to implement encoding- and profile-independent quality monitors. 
> ..."
>
> Therefore, you have no technical ground to assert that RTP clock rate
> MUST be equal to input media sampling frequency.
>
> Please think of VMR-WB as a dual-rate system where both 8000 and 16000
> Hz sampled media are supported and that decoding can proceed without 
> knowing the input media sampling frequency.
>
> Please remember that initially I resisted this idea; however, after
> considering all aspects of the requested change, I came to realize 
> that it is technically sound.
>
> I do want a resolution for this matter. This is definitely
> jeopardizing and delaying the deployment of VMR-WB codec and its 
> prospective applications. Please do not expect that the other parties 
> to back off from their position. We must resolve this issue.
>
> 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

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Oct 2004 09:38:30 +0100

Gino,

Thanks - this is a much more compelling explanation of the problem. The 
issue with switching between sampling rates in an RTP session is a well 
known problem with the way audio payload formats have been defined in 
the RTP/AVP profile. If you want to work to solve that in the general 
case, I would support that work. However, introducing workarounds for 
specific codec - making it inconsistent with the others in the profile 
- doesn't seem like a good idea to me.

On 5 Oct 2004, at 05:58, Scribano Gino-QA1087 wrote:
> It seems that the 'sampling rate' issue has now crossed over to the 
> Storage Format thread. In any case, it's been a while since my initial 
> comments regarding application impacts of restricting the RTP 
> timestamp to be equivalent to the source media sampling rate. So, I 
> would like to reiterate that the impact of this restriction extends 
> well beyond saving a few bytes of storage in a tone generation box. As 
> I stated previously, this restriction is also problematic for mixing 
> and/or switching diverse media sources in streaming and conversational 
> applications.
>
> Consider a conference bridging application, where at least one party 
> is a land-line circuit (which requires 8 KHz sampling) and at least 
> one other party is a wideband VMR-WB terminal (which may employ 16 KHz 
> sampling). Conference bridging for these media streams requires 
> switching and/or mixing the input streams into like output streams. 
> According to your restricted method, use of the VMR-WB sample rate 
> adaptation function for this application requires end-to-end session 
> renegotiation (eg, an SDP offer-answer cycle for each leg) in order to 
> achieve a common sampling rate, and hence timestamp interval, for all 
> RTP terminations involved in the conference bridge.

I would have thought the conference bridge could act as an RTP 
translator, and resample as appropriate for some participants?

> Additional latencies and synchronization complexities associated with 
> end-to-end renegotiation of the sampling rate for all RTP terminations 
> should not be required to establish and maintain the bridge in such 
> applications.

Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 06 Oct 2004 21:20:03 -0500

Colin,

Colin Perkins wrote:

<snip>

> translator, and resample as appropriate for some participants?

Use this as an example - here we have the advanced codec vmr-wb saying "you no longer need 
to worry about resampling at the bridge. Just send me the frames and I can handle them at 
either rates (8k or 16k)." But RTP payload says: "No, you cann't do that, even I know you 
are capable of it. You still have to stick with the tradition and pay the cost of signaling 
the rate change and building the resampling function into the bridge." I think this as a 
failure of taking full advantage of the codec capability.

regards,
-Qiaobing

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Oct 2004 13:52:58 +0100

On 7 Oct 2004, at 03:20, Qiaobing Xie wrote:
> Use this as an example - here we have the advanced codec vmr-wb saying 
> "you no longer need to worry about resampling at the bridge. Just send 
> me the frames and I can handle them at either rates (8k or 16k)." But 
> RTP payload says: "No, you cann't do that, even I know you are capable 
> of it. You still have to stick with the tradition and pay the cost of 
> signaling the rate change and building the resampling function into 
> the bridge." I think this as a failure of taking full advantage of the 
> codec capability.

I don't disagree. However, we need to develop a solution that retains 
the utility and extensibility of RTP and RTP implementations.

My concern with a fixed 16 kHz rate for VMR-WB is that it doesn't allow 
payload format independent implementations, since it offers a differing 
interpretation of the RTP timestamp than do other audio payload 
formats. To some extent that's unavoidable when we move to variable 
rate codecs, but it would greatly benefit implementers if we could 
develop a single approach to supporting variable rate codecs.

-- 
Colin Perkins
http://csperkins.org/