RTP Timestamp issue in Dial with moh option (-m)

Asterisk Asterisk Support
1

Hi Everyone,

I have the following scenario:
Dialer -----» Asterisk ----→ Destination

The call arrives from the Dialer to Asterisk which forwards it to the Destination
I am using the moh option (-m) in the Dial command to forward this call:

exten => 2000,1,Answer()
same  => n,Set(VOLUME(RX)=3)
same  => n,Set(VOLUME(TX)=3)
same  => n,Set(CALLFILENAME=${UNIQUEID}.${RAND(100000,999999)}.wav)
same  => n,MixMonitor(${CALLFILENAME})
same => n,Dial(PJSIP/anonymous/sip:+1XXXXXXX@172.xx.xx.84,,m(music))
same => n(,Hangup()

In this scenario, MOH is heard, but the Dialer is losing the initial audio of the Destination after the attend the call.

We have verified that this is due to the increase in Jitter when sending the RTP from Asterisk to the Dialer:

scrrenshot 2024-10-30 10-13-08
scrrenshot 2024-10-30 10-13-081920×960 272 KB

This increase in Jitter is caused by the large change in the Timestamp of the RTP header sent. Here are the RTP packets traced at the time of the increase in Jitter:

"58576","2024-10-28 14:06:37,569043274"
Real-Time Transport Protocol
    [Stream setup by HEUR RTP (frame 58183)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 22259
    [Extended sequence number: 87795]
    Timestamp: 19040
    Synchronization Source identifier: 0x42cfa1f0 (1120903664)


"58579","2024-10-28 14:06:37,589044575"
Real-Time Transport Protocol
    [Stream setup by HEUR RTP (frame 58183)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 22260
    [Extended sequence number: 87796]
    Timestamp: 19200
    Synchronization Source identifier: 0x42cfa1f0 (1120903664)


"58584","2024-10-28 14:06:37,609088497"
Real-Time Transport Protocol
    [Stream setup by HEUR RTP (frame 58183)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 22261
    [Extended sequence number: 87797]
    Timestamp: 38424
    Synchronization Source identifier: 0x42cfa1f0 (1120903664)

While Asterisk was sending the MOH, it generated its own Timestamp (18980,19040,19200).
When Destination answered the call, it began to re-transmit to Dialer the RTP messages with the Timestamp generated by Destination(38424), causing an increase in Jitter.

How can I get around this? Is there any way for Asterisk to rewrite the Timestamp of the re-transmitted RTP, or change some RTP header so that this Jitter is supported by the Dialer?

Thanks in advance

2

Although, historically, there have been issues with oversimplified handling of SSRC and timestamps, I’m not sure that that is still the case, and, in this case, it sounds to me as though the problem is different.

I think you need to investigate the B side RTP to see if the the B party has omitted frames and failed to update the timestamp, or whether Asterisk has queued up frames received during the MOH and has regurgitated them. As far as I know, the latter shouldn’t happen, because when the A side channel is originating MOH, it should be flushing incoming media.

3

Actually, I don’t understand how you get media through from the destination, before the MOH! I think your analysis of the source of the timestamps may be wrong.

(Historically, Asterisk didn’t pass timestamps through, but that may have changed.)

4

Hi David,

thanks for your answer.

In fact, Asterisk first sends the MOH media to the Dialer, then the Destination media.

Below are the traces from both sides of the call by Asterisk. ( Dialer-Asterisk and Asterisk-Destination). Rate remains around 20 ms (delta_min = 14.98 ms and delta_máx = 32.16 ms), consistent with the PCMA and PCMU Codecs.
These traces also show the Timestamp of each RTP packet, along with the Sequence, ssrc and Maker.

Trace Dialer-Asterisk
In this trace we can see the separatio
n of the RTP packets from the MOH media and the media coming from the Destination:

Asterisk_Dialer
Asterisk_Dialer1920×960 287 KB

Trace Asterisk-Destination
In this trace is show the separation of the media before and after the call is answered (the Destination starts sending the RTP packets before the call is answered). At this point, the Timestamp value matches the Timestamp shown in the Dialer-Asterisk trace.(38424).

Asterisk_Destination
Asterisk_Destination1920×960 288 KB

>>I think you need to investigate the B side RTP to see if the the B party has omitted frames and >>failed to update the timestamp
There is no RTP packet loss and side B is sending timestamp correctly (increment 160 on PCMU)

Note: Version Asterisk: 18.13.0