Subject: RE: [AVT] Issue with different timestamp frequencies

From: "O'Connor, Kevin" <[email-masked]>
Date: Tue, 31 Jan 2006 10:51:27 -0500

How would this be handled:

Seq nr.      TS      Rate
1            0       8k
2            160     8k
3            320     8k
4            800     16k
5            1120    16k
6            1440    16k
7            1760    8k
8            1920    8k

Between SN 3 and SN 4 there is a timestamp gap of 320 samples. Are these
samples at 8k or 16k? Can I assume that a rate change will only occur at
the beginning of an RTP packet and not during a silence gap in the
timestamps? Even with that assumption we have the issue of lost packets:

Seq nr.      TS      Rate
1            0       8k
2            160     8k
3            320     8k
5            800     16k
6            1120    16k
7            1440    16k
8            1760    8k
9            1920    8k

SN 4 was lost, but was it at 8k (coupled with a 20ms silence gap) or
16k? If the RTP receiver guesses wrong, it will instantly offset it's
clock by 20ms. Since packet loss typically comes in bursts, the offset
could be much greater.

One attractive feature of wideband VoIP is the ability to fall back to
narrowband when necessary, but I've been hesitant to implement this as
it requires too many guesses and assumptions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: Tuesday, January 31, 2006 5:35 AM
To: IETF AVT WG
Cc: Franceschini Guido
Subject: Re: [AVT] Issue with different timestamp frequencies

Hi,

I think I should clarify my view on how this work. It is allowed and do 
work to switch payload types with different timestamp rates within a 
single SSRC, i.e. timestamp and sequence number space, between payload 
types of different RTP timestamp rate. However some care is needed.

Lets assume that we have one payload type of rate with 8kHz and another 
with 16kHz. Both uses 20 ms frame lengths and each packet will contain 
only 20 ms of media.

Seq nr.      TS      Rate
1            0       8k
2            160     8k
3            320     8k
4            480     16k
5            800     16k
6            1120    16k
7            1440    8k
8            1600    8k

the 4th packet with the new frame rate indicates to the receiver that 
the new RTP timestamp rate will be used for all RTP and RTCP related 
functions from this point forward until a new timestamp rate is used 
again. The switching of rates must start with a media packet and it and 
the previous packet should not overlap, i.e. packet 4's content should 
not be overlapping with packet 3's content. In this case this they are 
nicely aligned. Packet 3 contains 160 samples at 8kHz and the next 
frames timestamp will be 480. In the next packet the rate has switched 
to 16k starting at TS 480. The fact that the timestamp runs with the 
current rate over the complete media content for a packet is also seen 
at the switch with packet 7. Which TS is 320 larger than packet 6's.

When performing these switches that are indicated using payload types 
the sender should also take care to not switch often. There are several 
reasons for that.
1. The receiver may not be able to determine the switch point if packet 
losses occur at the point of switching. In that case an RTCP SR are 
required to determine the switch point. Thus switching provides a 
potential loss of synchronization and this risk should be minimized.

2. The media codec switch may have substantial overhead or reduction in 
quality associated with it.

A further result of the above is the need to have any supporting or 
alternative encoding be able to use the same timestamp rate as the main 
one uses. This especially has implications for RFC 2833 when sending 
DTMF tones in addition or interleaved with the main audio encoding. The 
same applies for RFC2198 where the transmission of redundant encoding 
must use the same rate, and also the payload type for redundant payload 
must be signaled with the correct rate. Thus to use RFC 2198 at two 
different rates will in most cases require 6 payload types: 1 for first 
rate primary encoding, one for redundant encoding at first rate, and 
then one for the RFC 2198 payload format at the first rate, then the 
same set for the second TS rate.

Questions or comments?

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2006 18:17:33 +0100

Hi Kevin,

See inline.

> timestamps? Even with that assumption we have the issue of lost packets:

In this case the new sample change occurs at the beginning of packet 4, 
i.e. up until 800 the clock goes with 8kHz and from 8 and forward it is 
16k. Thus if packet 3 contains less than 480 ticks of media, then there 
is a gap of the media.

The RTCP sender report will also clarify this as it will provide NTP to 
TS binding for the new rate. The sender will have to update its RTCP 
Sender report to correctly identify the point of switching rate.

> clock by 20ms. Since packet loss typically comes in bursts, the offset

A RTCP sender report received after the packet loss will resolve this 
issue. However until that happens you are in the unknown which case that 
did occur. One can try to guess, but it might as well be discontinuous 
transmission as switching point.

> it requires too many guesses and assumptions.

I don't think there are any guesses. There are periods of uncertainty 
that are later resolved if one uses RTCP. The issue as I see it is 
probably the lack of implementation of these cases.

Note: Thinking loud and not verified, may contain issues and errors:

An alternative to switching timestamp rate for a particular SSRC would 
be to start the new rate using another SSRC than the previous one. This 
avoids the issue of handling the change of the rate. However the 
synchronization problem that might occur in case of packet loss in the 
above always happens at startup.

Cheers

Magnus Westerlund