Subject: RE: [AVT] RTP Timestamp Frequency Change Handling

From: "O'Connor, Kevin" <[email-masked]>
Date: Thu, 17 Feb 2005 09:39:32 -0500

Thank you for the clarification. I assume that if there is suppressed
silence prior to the payload type change, the missing timestamps
representing that silence are assumed to be at the previous payload
type's frequency. Is that correct?

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, February 17, 2005 7:29 AM
To: O'Connor, Kevin
Cc: [email-masked]
Subject: Re: [AVT] RTP Timestamp Frequency Change Handling

Hi Kevin,

O'Connor, Kevin wrote:
> RFC 3550 states that the payload type of an RTP stream can change at
any time, and that the timestamp frequency is dependent on the payload
type. If the payload type changes mid-stream in a way that changes the
frequency of the timestamp (from 16kHz to 8kHz for example), how should
this be handled by the RTP receiver? Will the new timestamps continue
where the old left off (and now at the different frequency), or will
they be consistent with their wall-clock time association (meaning that
timestamp values could jump backward and forward at payload type
transitions)? Or, is a new random starting timestamp chosen?

The answer is that it needs to be continuous, having it jump is not an 
option. So an example of how it should behave:
Wall time: 0, TS: 0 TS freq:8kHz
Wall time 3.0 s TS: 24000 TS freq:8kHz
Lets change the TS frequency at exactly
Wall time: 6.0 TS: 48000 and From here TS frequency is 16kHz
Then the wall time 9.0 the TS value will be 96000.

One has simply to say that from a specific TS value the new frequency 
will be used. And that point should correspond to the first media packet

at the new frequency.

There are a few words of caution that should be provided here. If that 
first media packet is lost, the synchronization is not established until

the next RTCP packet is received, because the receiver will not know 
without RTCP exactly when the change actually happened. Frequent 
switching would create great problems as there is need for RTCP to 
maintain synchronization in the case of packet losses.

Although allowed by the specification, I expect many implementations to 
have problems with a RTP payload switching that result in a change of 
used timestamp frequency.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Feb 2005 15:54:55 +0100

> type's frequency. Is that correct?

I would say yes, however you need to confirm that this is the truth 
based on the RTCP sender reports.

Cheers

Magnus Westerlund