Transcoder path stops working sporadically

[greenfieldtech-nirs]

Upon using Opus with Asterisk 14.7.X or Asterisk 15.5.0 an issue is exhibited, where the codec will simply stop transcoding in a certain direction. For example:

UA (A) ----- Opus -----> Asterisk ---- ulaw -----> PSTN Phone (B)

In the above case, after an unknown period of time the audio path from (A) to (B) is no longer audioable, while the path from (B) to (A) is still available.

A debug of Asteris and 'rtp set debug on' produced the following output:

[Aug 20 19:56:10] DEBUG[13263][C-00000002]: translate.c:756 ast_translate: Sample size different 960 vs 160 Sent RTP packet to 167.99.150.244:14962 (type 08, seq 034158, ts 1722888, len 000160) Got RTP packet from 167.99.150.244:14962 (type 08, seq 030122, ts 4209377896, len 000160) [Aug 20 19:56:10] DEBUG[13263][C-00000002]: translate.c:756 ast_translate: Sample size different 160 vs 960 Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029180, ts 10333536, len 000128) [Aug 20 19:56:10] DEBUG[13263][C-00000002]: translate.c:756 ast_translate: Sample size different 960 vs 160 Sent RTP packet to 167.99.150.244:14962 (type 08, seq 034159, ts 1723048, len 000160) Got RTP packet from 167.99.150.244:14962 (type 08, seq 030123, ts 4209378056, len 000160) [Aug 20 19:56:10] DEBUG[13263][C-00000002]: translate.c:756 ast_translate: Sample size different 160 vs 960 Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029181, ts 10334496, len 000099) [Aug 20 19:56:10] DEBUG[13263][C-00000002]: translate.c:756 ast_translate: Sample size different 960 vs 160 Sent RTP packet to 167.99.150.244:14962 (type 08, seq 034160, ts 1723208, len 000160) [Aug 20 19:56:10] DEBUG[13252][C-00000002]: res_rtp_asterisk.c:5457 ast_rtcp_interpret: Got RTCP report of 64 bytes from 54.210.151.172:36191 [Aug 20 19:56:10] NOTICE[13252][C-00000002]: translate.c:594 ast_translate: 10996 lost frame(s) 41118/30121 (slin@48000)->(opus@48000)

Now, after that happens, we shortly see the following:

Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029219, ts 10370976, len 000128) [Aug 20 19:56:11] NOTICE[13252][C-00000002]: translate.c:594 ast_translate: 24380 lost frame(s) 0/41154 (opus@48000)->(slin@48000) Got RTP packet from 167.99.150.244:14962 (type 08, seq 030162, ts 4209384296, len 000160)

Which turns into:

[Aug 20 19:56:11] WARNING[13252][C-00000002]: channel.c:1136 __ast_queue_frame: Exceptionally long queue length queuing to SIP/subscribers.xxxxxxxxx.com-00000002 Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029220, ts 10371936, len 000128) Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029221, ts 10372896, len 000128) Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029222, ts 10373856, len 000128) Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029223, ts 10374816, len 000128) Sent RTP packet to 54.210.151.172:36190 (type 107, seq 029224, ts 10375776, len 000128)

Which at that point loses audio completely from (A) towards (B).

The issue is re-produceable and happens constantly, however, will happen at different intervals.

[traud]

You applied the patch for Native PLC. That patch is experimental. Please, undo that patch and try again.

A) If that was the cause, please continue there… B) If not, I need much more details to reproduce your issue:

1. Who created your user-agent (UA), which model, and which firmware version is running on it?
2. Do you face similar issues with iLBC?
3. About which timeframes do we talk, minutes, hours?

[greenfieldtech-nirs]

Hmmmm... I don't recall adding that patch in, but could be. try and report back.

[traud]

lost frame(s)

This log output came with the patch. Somehow in your scenario, the sequence numbers of the RTP packets are not +1 as expected. This should be visible via Wireshark as well. If this is the cause for your no-audio symptom, please, double-check what causes that. Are you using SIP Session Timers? Asterisk active them on default. However, many implementations are terrible wrong and reset all kind of stuff on the re-INVITE message.

[greenfieldtech-nirs]

We noticed the issue, seems like one of the experimental patches got in there and messed things up. Thanks for the assist.