DTMF is not sent properly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install Kelpie and Asterisk. Configure Keplie to be a gateway between 
Asterisk and GTalk
2. Send DTMF with /dial:12345

The expected behaviour: digits arrive to Asterisk and it is possible to use IVR.

Sometimes digits are sent, but not all of them. 

2012-12-31 19:30:17,198 DEBUG kelpie.RtpRelay - [[CS00000020]] Preparing to 
send dtmf 5

When it is sent I see on the console of Asterisk:
[2012-12-31 19:34:34] DTMF[27538]: channel.c:3981 __ast_read: DTMF end '5' 
received on SIP/w-000046a7, duration 0 ms
[2012-12-31 19:34:34] DTMF[27538]: channel.c:4039 __ast_read: DTMF end accepted 
without begin '5' on SIP/w-000046a7
[2012-12-31 19:34:34] DTMF[27538]: channel.c:4050 __ast_read: DTMF end 
passthrough '5' on SIP/w-000046a7

Kelpie logs all DTMF codes. When I send /dial:1234

I see in the log:
2012-12-31 19:51:21,033 DEBUG kelpie.Session - [[GWS00000011]] Call found, 
sending dtmfs
2012-12-31 19:51:21,033 DEBUG kelpie.RtpRelay - [[CS00000026]] Logging dtmf 1 
for generation
2012-12-31 19:51:21,033 DEBUG kelpie.RtpRelay - [[CS00000026]] Logging dtmf 2 
for generation
2012-12-31 19:51:21,033 DEBUG kelpie.RtpRelay - [[CS00000026]] Logging dtmf 3 
for generation
2012-12-31 19:51:21,033 DEBUG kelpie.RtpRelay - [[CS00000026]] Logging dtmf 4 
for generation
2012-12-31 19:51:21,033 DEBUG kelpie.RtpRelay - [[CS00000026]] Preparing to 
send dtmf 1
2012-12-31 19:51:21,284 DEBUG kelpie.RtpRelay - [[CS00000026]] Running 
RtpRelay::StunTransmitter ... : /78.27.190.13:3851 -- 8153
2012-12-31 19:51:21,444 DEBUG kelpie.RtpRelay - Local User found f0c21bb9

kelpie-0.1
Linux 2.6.32-5-amd64 #1 SMP x86_64 GNU/Linux
Asterisk 1.8.x

Can provide more logs upon request.

Original issue reported on code.google.com by Yukko.Se...@gmail.com on 31 Dec 2012 at 6:52

[GoogleCodeExporter]

Hi Sergey,

I cannot replicate your problem, could you attach full logs (after the 1st DTMF 
is sent out as shown above up to the received one) and a pcap from either or 
both sides for this issue?

Thanks,

Lorenzo

Original comment by lorenzo.mangani on 1 Jan 2013 at 3:49

[GoogleCodeExporter]

Hello.

I have attached 3 (slightly modified) files. One is a kelpie call log. Another 
is Asterisk console output for the same call. The third file is a SIP trace for 
another similar call with the same digits entered during the session, but as I 
understand DTMF is sent inband, so the SIP trace has no data about digits. 

Asterisk has 
dtmfmode=auto
relaxdtmf=yes

Original comment by Yukko.Se...@gmail.com on 1 Jan 2013 at 4:37

Attachments:

• kelpie.call.txt
• asterisk.call.txt
• sip.trace.kelpie.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Sergey,

Please see my original reply, a tcpdump/wireshark pcap with the "RTP EVENT" 
traffic capture is required to see what's actually sent by kelpie vs. received 
by asterisk [RTP EVENT  Payload type=RTP Event, DTMF Four 4] - comparing that to 
a working trace where you send DTMF to your application might already suggest 
the cause, most likely timing related.

Thanks,

Lorenzo

Original comment by lorenzo.mangani on 1 Jan 2013 at 6:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I checked pcap file after sending  /dial:12345
It has only the first digit '1'

Original comment by Yukko.Se...@gmail.com on 1 Jan 2013 at 7:39

Attachments:

• dtmf_capture.1.pcap

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The QXIP Kelpie fork provides optional SIP INFO DTMF signaling, this switch 
solves this interoperability case as confirmed by Sergey above after testing 
both methods (will provide patch for Kelpie asap, menawhile for anyone with the 
same issue: 
https://github.com/lmangani/kelpie/commit/c417d7995665c885361adeb7727a86ce82cf79
03)

Thanks,

Lorenzo

Original comment by lorenzo.mangani on 1 Jan 2013 at 10:34

[GoogleCodeExporter]

DTMF INFO feature merged in r54
https://code.google.com/p/kelpie/source/detail?r=54

Original comment by lorenzo.mangani on 8 Jan 2013 at 11:16

[GoogleCodeExporter]

Yes. I was able to solve my interoperability problems after I added to the 
configuration file this string:

com.voxbone.kelpie.feature.dtmf-info=true

Original comment by Yukko.Se...@gmail.com on 8 Jan 2013 at 6:56