Asterisk Is Delaying DTMF INFO In Meetme

Home » Asterisk Users » Asterisk Is Delaying DTMF INFO In Meetme
Asterisk Users No Comments

Hi List,

We have a major issue while broadcasting DTMF using meetme application. We are sending DTMF to asterisk using SIP INFO message with duration 160.

INFO sip:xxx@xxx SIP/2.0
Via: SIP/2.0/UDP xxx:5060
From: ;tag=43
To: ;tag=9753.0207
Call-ID: xxx@xxx CSeq: 25634 INFO
Content-Length: 26
Content-Type: application/dtmf-relay Signal= 2\r\n Duration= 160\r\n

[Nov 19 15:30:43] [1;32mDEBUG[0m[2966]:[1;37mchan_sip.c[0m:[1;37m24896[0m [1;37mhandle_incoming[0m: **** Received INFO (13) – Command in SIP INFO
Receiving INFO!
* DTMF-relay event received: 2
[KCentOS-2*CLI> [0K[Nov 19 15:30:43] [[1;32mDTMF[[0m[17988]: [[1;37mchannel.c[[0m:[[1;37m3978[[0m [[1;37m__ast_read[[0m: DTMF end ‘2’ received on SIP/16222-00000037, duration 160 ms M[[KCentOS-2*CLI> M[[0K[Nov 19 15:30:43] [[1;32mDTMF[[0m[17988]: [[1;37mchannel.c[[0m:[[1;37m4004[[0m [[1;37m__ast_read[[0m: DTMF begin emulation of ‘2’ with duration 160 queued on SIP/16222-00000037
[Nov 19 15:30:45] [[1;32mDTMF[[0m[17988]: [[1;37mchannel.c[[0m:[[1;37m4096[[0m [[1;37m__ast_read[[0m: DTMF end emulation of ‘2’ queued on SIP/16222-00000037
[Nov 19 15:30:45] [[1;32mDEBUG[[0m[17988]: [[1;37mchan_sip.c[[0m:[[1;37m3328[[0m [[1;37m__sip_xmit[[0m: Trying to put ‘INFO sip:18’ onto UDP socket destined for 132.186.230.236:6372

From the above log (Nov 19 15:30:43 and Nov 19 15:30:45)I can see that after receiving SIP INFO asterisk is trying to regenerate the DTMF tone based on the duration specified by the client. Which is OK, but latency observed in this operation is more than 2 Sec in some cases and also asterisk changes the duration field in SIP INFO message body. Please help us out to overcome this problem as more than 2 sec latency is not acceptable in real-time scenarios. Also if possible let us know (technically), whether it is a know issue in asterisk.

Regards Rajib