Subject: [AVT] Issue with different timestamp frequencies

From: Franceschini Guido <[email-masked]>
Date: Mon, 30 Jan 2006 14:22:49 +0100

Dear experts,

I went through an issue that I am not confident to solve by myself, and
for which I would greatly appreciate the advice of this group.

The scenario is: VoIP + DTMF

The issue arose as soon as we introduced WideBand codecs. Indeed, with
SDP we can now offer WB (resolution 16000) as well as NB (resolution
8000) audio codecs, in conjunction with the "telephone-event".
All in a single RTP session.

The SDP offer looks something like:

m=audio 50000 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR-WB/16000
a=rtpmap:99 telephone-event/8000

To my knowledge, nothing prevents to negotiate codecs with different
timestamp frequency, thus, e.g. AMR-WB + DTMF
In such a case however we have a problem with RTCP reports, since they
use the RTP timestamp units (thus 8000 or 16000) for computing the
Interarrival Jitter (in SR and RR) and the RTP Timestamp (in SR) fields.

Since each RTCP report block is scoped by a single SSRC, a possible
solution I thougth about is to send data on the different PTs using
different SSRCs (and thus different SN and TS offsets). This is not
obvious (I haven't read about such a constraint anywhere), and also a
bit heavy in terms of RTCP overhead. I have then legacy implementation
using AMR and DTMF only, that share a single SSRC/TSoffset/SNoffset
space, thus I should probably better employ different sets of
SSRC/TSoffset/SNoffset only when multiple resolutions are negotiated.

Another approach that I considered is to use separate sockets for each
resolution, but this would create more issues with the legacy I have
(and is also a constraint that I have not seen anywhere)

Anyway, the usage of DTMF is just a detail, since the problem would
identically occur for any negotiation of audio codecs with different
sampling rates.

Did I miss some rule/constraint here and there?
Is there any other viable/advisable approach?

Thanks in advance
Guido Franceschini
Telecom Italia

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Jan 2006 15:01:40 +0100

Hi,

RTP doesn't handle timestamp switches that well. In this case I would 
recommend that you define two DTMF payload types one for 8kHz and one 
with 16 kHz. That way you can avoid having switches due to the 
interspersed DTMF signalling.

Thus you would either have 8 or 16 kHz TS rate for long blocks. Thus 
making little difference than a 8kHz only session would have. The change 
in used timestamp rate is at the point when the first packet is sent 
with a new rate. If that packet is lost, RTCP will tell the receiver 
when this occurred. However this won't work if one switch TS rate every 
second packet.

Cheers

Magnus

-- 

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]

---

From: [email-masked]
Date: Tue, 31 Jan 2006 09:17:46 +0100

fyi,
just a side info, last ITU-T WP2/16 meeting did also touch the topic of
multiple timestamp frequencies:

Relative vs Absolute Time

http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/AVD-2800.zip

Albrecht
ALCATEL

                      Magnus Westerlund                                                                                                 
                      <magnus.westerlund@er         To:      Franceschini Guido <[email-masked]>                          
                      icsson.com>                   cc:      IETF AVT WG <[email-masked]>                                                 
                      Sent by:                      Subject: Re: [AVT] Issue with different timestamp frequencies                       
                      [email-masked]                                                                                              

                      30.01.2006 15:01                                                                                                  

Hi,

Cheers

Magnus

--

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 Jan 2006 09:34:37 +0000

> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/AVD-2800.zip

That appears to be significantly misinterpreting previous discussion  
in AVT, to make a case for variable timestamps within a single media  
stream.  That has serious problems, and was not the result of the AVT  
discussions on this subject (which were about codecs which use a  
single RTP timestamp rate, different to the media sampling rate).

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2006 11:34:45 +0100

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 Jan 2006 11:36:53 +0000

On 31 Jan 2006, at 10:34, Magnus Westerlund wrote:
> 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.

While this is all legal, it's not clear how many receivers have such  
a sophisticated playout buffer in practise.

> 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.

Switching payload type will make this more obvious, since you have  
the signalled clock rate for the new payload type.

> 2. The media codec switch may have substantial overhead or  
> reduction in quality associated with it.
>
> 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.

Switching RTP timestamp during a session will also likely invalidate  
the RTCP jitter statistics and round-trip time estimator, and might  
also confuse RTCP XR reports.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2006 16:45:24 +0100

Hi,

I wasn't very clear on this. All timestamp rate changes are indicated by 
the change of the RTP payload type, as each RTP payload type can only 
have one and only one timestamp rate associated to them.

Colin Perkins wrote:
> While this is all legal, it's not clear how many receivers have such a 
> sophisticated playout buffer in practise.

Yes, these are necessary not easy operations and do require fair amount 
of special handling. But for application that do need them, they are 
possible to use. But for interoperability it is probably safer to avoid 
changing the RTP timestamp rate.

>> the sender should also take care to not switch often. There are 
>> several reasons for that.
>> 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 
> Switching payload type will make this more obvious, since you have the 
> signalled clock rate for the new payload type.

As I stated above, this is a necessity. The payload type is the only way 
of indicating a different RTP timestamp rate.

> 
> Switching RTP timestamp during a session will also likely invalidate the 
> RTCP jitter statistics and round-trip time estimator, and might also 
> confuse RTCP XR reports.

Agreed.

Cheers

Magnus Westerlund