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

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 9 Feb 2006 19:50:15 -0800

If the RTP loss occurs immediately after the switch, and if the RTCP SR
generated at that time is also lost, receiver cannot correct it's time
until the arrival of next SR. If the SR reporting interval is not small,
it might take significant time for the receiver to correct it's time
since the switching instance at the sender.

In the above case, if the VoIP session is using RTP/AVP profile (min
RTCP interval is 5 sec), there is a chance that receiver may not see
RTCP SR for significant amount of time.

Cheers,
Hari

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: Tuesday, January 31, 2006 9:18 AM
To: O'Connor, Kevin
Cc: IETF AVT WG
Subject: Re: [AVT] Issue with different timestamp frequencies

Hi Kevin,

See inline.

O'Connor, Kevin wrote:
> 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:

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.

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

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.

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

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

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