On Jun 1, 2016 9:37 PM, "Holger Freyther" holger@freyther.de wrote:
On 01 Jun 2016, at 17:18, Max msuraev@sysmocom.de wrote:
Hi.
Right now in osmobts when sending/receiving frames with osmo_rtp_* it's assumed that no frame is lost and timestamp is always advanced in 160ms steps. In practice (especially when DTX is in place) frames do get lost so we have to adjust the step to compensate.
However the result sound not much better than using hardcoded value which suggest that I might be doing FN -> ms conversion (or smth else) wrong. Any ideas/advices?
Don't do it. I don't find the relevant spec within the time frame I had
but I think I recently saw a piece of documentation that SQN (and timestamp) should only be incremented if data is being sent.
Either in the RTP RFC, RTP AMR RFC or the A over IP spec.. I think I saw
it while going through the documents Harald had pointed while I introduced my ideas for the SIP connector.
It's in the RTP RFC.
Sequence number is incremented by 1 with every packet, even if the packet is sent after a long pause (due to DTX). This way you know when you miss a packet.
Timestamp is measured in samples and this is incremented by a number of samples since the last packet. This way you know when to start playing the packet in case of DTX.
A proper RTP library or rather a jitter buffer should handle this automatically, but I'm not sure how does ortp handle it.
Please excuse typos. Written with a touchscreen keyboard.
-- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co
Hi Alexander and Max,
I don't really have to add anything to what Alexander wrote, but to make it super-clear:
On Wed, Jun 01, 2016 at 10:51:47PM +0300, Alexander Chemeris wrote:
Sequence number is incremented by 1 with every packet, even if the packet is sent after a long pause (due to DTX). This way you know when you miss a packet.
correct, and makes sense.
Timestamp is measured in samples and this is incremented by a number of samples since the last packet. This way you know when to start playing the packet in case of DTX.
correct. How would a receiver ever know when to play back a given packet, if there was no constantly-incrementing timestamp generated by the transmitter sample clock. So this clock needs to continue to coult (like a ADC sample clock), whether we currently transmit RTP codec frames, or whether we currently suppress sending some codec frames.
So in short: sqeuence numbers will increment by one with each frame transmitted, and timestamp will expose gaps while DTX is used.
A proper RTP library or rather a jitter buffer should handle this automatically, but I'm not sure how does ortp handle it.
that's the receiving side. The transmitter will have to put correct values in the frames, which we are not doing in osmo-bts at the moment.
-
Alexander Chemeris -
Harald Welte