Why no DTMF from sound file sent by callee?

We “Playback” a converted .wav file on an answered phone but the caller, i.e. the other
phone on the line, sees no DTMF on the caller phone. We’ve independantly verified that the sender does send sound containing DTMF tones. When we use asterisk AMI via “PlayDTMF” commands, the other phone on the call, i.e. non-sender receives DTMF.
We are concerned that the caller phone configuration is not “telling” it to look for / convert the audio to DTMF events where appropriate. The only thing we know about is the “dtmfmode => inband” setting which we place in the caller’s section of sip.conf.

We certainly would appreciate any help or suggestions with this issue.

Called phone’s extensions.conf segment:

exten => 45002,1,Verbose(Playback exten=${EXTEN})
same => n, Answer(1)
same => n, Playback(/nfs/newadmin/public/users/crs/testbuddy/log/ast87_ao1/01)
same => n, wait(30)
same => n, Hangup()

exten => _X.,1,Verbose(exten=${EXTEN})
same => n, Dial(SIP/${EXTEN}@
same => n, Hangup()

include => outgoing
include => incoming
exten => _X.,1,Verbose(exten=${EXTEN} default)
same => n,Goto(incoming,${EXTEN},1)[/code]

Caller’s extensions.conf segment:


        ; OXE phones
        ; registrar = ao1-oxe-ed.inse.lucent.com
        ; registrar ip =

            exten => 51207,1,Verbose(51207 outgoing)
            same => n,Wait(1)
            same => n,Dial(SIP/51207@,20,rt)
            same => n,wait(99999)[/code]

Caller’s sip.conf segment:

; OXE client sections
dtmfmode => inband


From the calls dtmf log:

[Feb 26 13:18:20] Asterisk 11.12.1 built by root @ rsmith-linux1 on a i686 running Linux on 2014-09-25 15:04:32 UTC log/ast87_ao1/dtmf_file (END)

Relevant segment from CLI:

[Feb 26 13:19:27] DEBUG[32660][C-00000000]: pbx.c:4883 pbx_extension_helper: Launching ‘Verbose’
– Executing [45002@externalphone:1] Verbose(“SIP/”, “Playback exten=45002”) in new stack
Playback exten=45002
[Feb 26 13:19:27] DEBUG[32660][C-00000000]: pbx.c:4883 pbx_extension_helper: Launching ‘Answer’
– Executing [45002@externalphone:2] Answer(“SIP/”, “1”) in new stack
[Feb 26 13:19:27] DEBUG[32660][C-00000000]: pbx.c:4883 pbx_extension_helper: Launching ‘Playback’
– Executing [45002@externalphone:3] Playback(“SIP/”, “/nfs/newadmin/public/users/crs/testbuddy/log/ast87_ao1/01”) in new stack

<— SIP read from UDP: —>
INVITE sip:asterisk@ SIP/2.0
Contact: sip:
Supported: replaces,timer,path,100rel
User-Agent: OmniPCX Enterprise R11.0 k1.400.29.e
Session-Expires: 1800;refresher=uac
Min-SE: 900
Content-Type: application/sdp
To: sip:asterisk@;tag=as4a9481ac
From: sip:51207@;tag=2e9fc6133e470de774f20f63bdec12b5
Call-ID: 68f6e1227e2210dc72565d8346938637@
CSeq: 321844588 INVITE
Via: SIP/2.0/UDP;branch=z9hG4bKf904382b4361e1db4e91e0b65005a1f7
Max-Forwards: 70
Content-Length: 221

o=OXE 1424974767 1424974768 IN IP4
c=IN IP4
t=0 0
m=audio 15056 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
— (15 headers 11 lines) —
Sending to (NAT)
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: chan_sip.c:25447 handle_request_invite: Initializing initreq for method INVITE - callid 68f6e1227e2210dc72565d8346938637@
Found RTP audio format 0
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: rtp_engine.c:557 ast_rtp_codecs_payloads_set_m_type: Setting payload 0 based on m type on 0xb642f868
Found RTP audio format 101
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: rtp_engine.c:557 ast_rtp_codecs_payloads_set_m_type: Setting payload 101 based on m type on 0xb642f868
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw), peer - audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: res_rtp_asterisk.c:4336 ast_rtp_remote_address_set: Setting RTCP address on RTP instance '0xb720c824’
Peer audio RTP is at port
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: res_rtp_asterisk.c:4246 ast_rtp_prop_set: Ignoring duplicate RTCP property on RTP instance ‘0xb720c824’
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: chan_sip.c:10663 process_sdp: Setting native formats after processing SDP. peer joint formats (ulaw), old nativeformats (ulaw)

<— Transmitting (NAT) to —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP;branch=z9hG4bKf904382b4361e1db4e91e0b65005a1f7;received=;rport=5060
From: sip:51207@;tag=2e9fc6133e470de774f20f63bdec12b5
To: sip:asterisk@;tag=as4a9481ac
Call-ID: 68f6e1227e2210dc72565d8346938637@
CSeq: 321844588 INVITE
Server: Asterisk PBX 11.12.1
Supported: replaces, timer
Session-Expires: 1800;refresher=uac
Contact: sip:asterisk@
Content-Length: 0

[Feb 26 13:19:27] DEBUG[32362][C-00000000]: chan_sip.c:13534 transmit_response_with_sdp: Setting framing from config on incoming call
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: chan_sip.c:13088 add_sdp: ** Our capability: (ulaw) Video flag: True Text flag: True
[Feb 26 13:19:27] DEBUG[32362][C-00000000]: chan_sip.c:13089 add_sdp: ** Our prefcodec: (slin)
Audio is at 11578
Adding codec 100003 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP[/code]

The recording probably only records audio frames. The DTMF is probably out of band at that point in the system.

Thank you for you rapid response.

The wave produced (and converted to Asterisk format) was recorded with AUDIO DTMF tones embeded. Our intent was to verify the accuracy of our systems creation and routing of AUDIO. The embeded
Our pre-Asterisk test setup uses the embeded DTMF tones and their recognition at the simulated phone end to recognize the particular audio file.

This recording file was originally a .wav file which we converted with the following sox command:
sox /nfs/newadmin/public/users/crs/testbuddy/dtmf/newzip/01.wav -t raw -r 8000 -s -2 -c 1 /nfs/newadmin/public/users/crs/testbuddy/log/ast87_ao1/01.sln

Is this going to preserve enough audio quality so that Asterisk (whith sip.conf including “dtmfmode => inband”) can recognize the DTMF tones as inband DTMF?

In our testing we have added phones to the setup and, when listening, can manually recognize what appear to be DTMF tones.

Thanks for you attention.

sln, ulaw and alaw should be OK for inband DTMF. gsm is definitely not and g.729 is probaby not.

I’m at a bit of a loss. We used the following and got no DTMF:
From our sip.conf
dtmfmode => inband


Even though it is sent inband to Asterisk, Asterisk still needs to convert it to out of band internally, in order that it can recognize tones.

No guarantees, but check that you have nothing enabled that would require Asterisk to recognize a tone.

I must be dense here, but I was hoping that Asterisk would be able to recognize tones from wave forms.
Is that not what the sip.conf “dtmfmode => inband” specification requests? I’m not sure what else I can specify or inspect to get Asterisk to recognize and convert DTMF tones embedded within a wave form to DTMF events.

Has anyone actually seen an example of Asterisk work in recognizing DTMF tones embedded within an wave file?

Thanks again for your help and patience.

I think I am confused at what you are trying to do. I can’t imagine anyone has even tried to recognize tones embedded in a file. I am pretty sure that DTMF detection is done on the inbound side of channels, and I doubt that it is done on local channels, which would be the only way of placing an inbound side after output from a file.

I think you need to state the goal, not the way you are trying to achieve it, and also provide some sort of block diagram of the way you are trying to achieve it.

We test our company’s collaboration software, which includes instant messaging, application sharing, audio and video conferencing, etc. Which we have been doing for years. Because of contractual reasons we have to stop using the phone simulation software package we have been using. I have been attempting to replace that package with Asterisk to some success, e.g. we can make and answer calls,

Our testing includes validation of routing and reception of audio prompt files. Our mechanism, used by others, has been to create a testing set of our prompts with embedded identifying DTMF tones, e.g 100 for prompt number 100. Our software then verifies the prompt received by recognizing the embeded DTMF. This has worked reasonably in the past. To handle some of the DTMF recognition problem we add redundancy to the embedded codes. To recognize possible clipping of the prompt signal we include a copy of the embedded identifying code at the beginning and end of the prompt wave form.

To summarize our problem, we use the embedded DTMF in wave files to aid in the automation of audio wave identification, but we have not been able to get Asterisk do do this for us.

I’m more confused. In the last but one message you were talking about Asterisk converting tones to events, but now you are talking about sending the tone to phone for the phone to convert to events.

I don’t think I’m going to get to the bottom of this in the time I’m prepared to spend.

I would note that one would normally use SendDTMF to originate tones.

We play the audio files to phones simulated by Asterisk.

Our audio files are created, with the embeded DTMF tones, separately. Our conference system plays these audio tones to phones (which we simulate using Asterisk). We verify proper system operation, that is the playing the expected tones (e.g. “Welcome…”) looking for the proper DTMF tone events (via Asterisk::AMI).

I hope this makes our operation/goals a bit clearer.

I appreciate you attention and help.