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

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt