[Home]

Summary:ASTERISK-17581: rtpkeepalive blocks incoming DTMF periodically
Reporter:geejay (geejay)Labels:
Date Opened:2011-03-19 06:21:36Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Core/RTP
Versions:1.4.40 13.18.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When {{rtpkeepalive}} is not zero then comfort noise packets are sent periodically. During sending of comfort noise packets incoming DTMF is not processed.

These DTMF tones are lost.

The Function {{ast_rtp_sendcng}} in {{rtp.c}} mutes DTMF for a certain period here:

{noformat}
rtp->dtmfmute = ast_tvadd(ast_tvnow(), ast_tv(0, 500000));
{noformat}

DTMF tones received during this period are not processed by Asterisk.

I verified the problem in Asterisk 1.4.40. The code 1.6.2.17.1 seems to be the same.

*Additional Info*

RTP debug. The first "5" DTMF tone is processed by Asterisk but the second "5" is ignored because Asterisk sends comfort noise.

{noformat}
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044204, ts 1634395254, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044204, ts 1634395254, len 000004, mark 1, event 00000005, end 0, duration 00000)
[Mar 19 09:38:28] DTMF[21798]: channel.c:2530 __ast_read: DTMF begin '5' received on SIP/xswitch-000003ba
[Mar 19 09:38:28] DTMF[21798]: channel.c:2534 __ast_read: DTMF begin ignored '5' on SIP/xswitch-000003ba
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044205, ts 1634395254, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044205, ts 1634395254, len 000004, mark 0, event 00000005, end 1, duration 01920)
[Mar 19 09:38:28] DTMF[21798]: channel.c:2449 __ast_read: DTMF end '5' received on SIP/xswitch-000003ba, duration 240 ms
[Mar 19 09:38:28] DTMF[21798]: channel.c:2515 __ast_read: DTMF end passthrough '5' on SIP/xswitch-000003ba
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044205, ts 1634395254, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044205, ts 1634395254, len 000004, mark 0, event 00000005, end 1, duration 01920)
Sent Comfort Noise RTP packet to 200.21.22.9:21196 (type 13, seq 30686, ts 0, len 1)
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044206, ts 1634397174, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044206, ts 1634397174, len 000004, mark 1, event 00000005, end 0, duration 00000)
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044207, ts 1634397174, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044207, ts 1634397174, len 000004, mark 0, event 00000005, end 1, duration 01680)
Got  RTP packet from    200.21.22.9:21196 (type 101, seq 044207, ts 1634397174, len 000004)
Got  RTP RFC2833 from   200.21.22.9:21196 (type 101, seq 044207, ts 1634397174, len 000004, mark 0, event 00000005, end 1, duration 01680)
{noformat}

Comments:By: rsw686 (rsw686) 2011-03-23 09:21:44

This could be related to 0018784 or 0018764, which affected DTMF processing. One was due to the silence generator being added. Both of these issues for me were resolved by issue 0015642 with revision 310888 for 1.4 "Don't delay DTMF in core bridge while listening for DTMF features".
By: geejay (geejay) 2011-03-25 23:34:30

I dont see how this is a related to those Sonus issues. The problem I describe here is much older.

The problem can be easily verified with a SIP trunk. Set rtpkeepalive=1 to generate comfort noise packets every second. Then send a call from the trunk to asterisk, answer the call and send DTMF RFC2833 packets to asterisk. You will notice excessive lost DTMF tones.