Asterisk version: 16.25.2
Problem description:
RTP Timestamp issue causes clicks & pops on calls routed via alternate Call Platforms.
Cause:
This means that a short frame following a typical frame should have a timestamp that is a typical frame offset in time, it is the frame after the short frame that should have a shorter timestamp offset. However this does not seem to be the case currently.
With a shortened packet, the wrong value will be written
static int rtp_raw_write(struct ast_rtp_instance *instance, struct ast_frame *frame, int codec)
{
struct ast_rtp *rtp = ast_rtp_instance_get_data(instance);
int pred, mark = 0;
unsigned int ms = calc_txstamp(rtp, &frame->delivery);
struct ast_sockaddr remote_address = { {0,} };
int rate = ast_rtp_get_rate(frame->subclass.format) / 1000;
unsigned int seqno;
#ifdef TEST_FRAMEWORK
struct ast_rtp_engine_test test = ast_rtp_instance_get_test(instance);
#endif
if (ast_format_cmp(frame->subclass.format, ast_format_g722) == AST_FORMAT_CMP_EQUAL) {
frame->samples /= 2;
}
if (rtp->sending_digit) {
return 0;
}
#ifdef TEST_FRAMEWORK
if (test && test->send_report) {
test->send_report = 0;
ast_rtcp_write(instance);
return 0;
}
#endif
if (frame->frametype == AST_FRAME_VOICE) {
pred = rtp->lastts + frame->samples;
/ Re-calculate last TS /
rtp->lastts = rtp->lastts + ms * rate;
if (ast_tvzero(frame->delivery)) {
/ If this isn’t an absolute delivery time, Check if it is close to our prediction,
and if so, go with our prediction */
if (abs((int)rtp->lastts - pred) < MAX_TIMESTAMP_SKEW) {
rtp->lastts = pred;
} else {
ast_debug_rtp(3, “(%p) RTP audio difference is %d, ms is %u\n”,
instance, abs((int)rtp->lastts - pred), ms);
mark = 1;
}
- RFC-3550
- 5.1 of the standard is direct:
The timestamp reflects the sampling instant of the first octet in the RTP data packet
This means that a short frame following a typical frame should have a timestamp that is a typical frame offset in time, it is the frame after the short frame that should have a shorter timestamp offset.2. In the discussion on jitter calculation, it explicitly refers to the need for the RTP timestamp to be like this:
Because the jitter calculation is based on the RTP timestamp which represents the instant when the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated. Such a variation in delay would occur for audio packets of varying duration.
- Appendix B changes since RFC-1889 refers to the fact this area has been reviewed and clarified:
The meaning of “sampling instant” was explained in more detail as part of the definition of the timestamp field of the RTP header in Section 5.1.
- Further note though, the Henning’s Schulzrinne’s own FAQ (lead author) for RTP says it is OK to have short frames. He doesn’t expand on timestamp requirements there though.