[asterisk-users] DTMF

[Jason Lixfeld]

On 21-Apr-09, at 1:06 PM, Anthony Francis wrote:

>> You are correct, not seeing that means that the signaling was  
>> either in
>> the audio stream (which doesn't survive compression) or it was sent  
>> in
>> the sip signaling. However one must also note that your ITSP's  
>> gateway
>> may have been having problems with their DTMF detection on their  
>> PRI's.
>>
>> Anthony
>>
>
> Also, to determine if you are sending DTMF out of band (as part of IAX
> signalling) do iax2 debug peer <connection name>
> in the CLI.
> You will see when it creates DTMF events.

Not being much of a DTMF guru, but trying to follow along the best I  
can in hopes of troubleshooting my own DTMF issues, I seem to be  
getting hung up having DTMF pass from a SIP channel to an IAX channel:

7970 -- SIP/ulaw -- ast -- IAX/ulaw -- ITSP

With:
core set debug channel IAX2/x.x.x.x-13779
and...
core set debug channel SIP/phone-cisco-1-089a55d0
... set, I generate DTMF via the ITSP and see:

<< [ TYPE: DTMF Begin (12) SUBCLASS: 2 (50) ] [IAX2/x.x.x.x-13779]
 >> [ TYPE: DTMF Begin (12) SUBCLASS: 2 (50) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: DTMF End (1) SUBCLASS: 2 (50) ] [IAX2/x.x.x.x-13779]
 >> [ TYPE: DTMF End (1) SUBCLASS: 2 (50) ] [SIP/phone-cisco-1-089a55d0]

So that tells me that ast is receiving DTMF from ITSP and sending it  
to my phone.

If I then try to generate DTMF via the phone towards the ITSP on the  
same call, I see:

<< [ TYPE: DTMF Begin (12) SUBCLASS: 2 (50) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: DTMF End (1) SUBCLASS: 2 (50) ] [SIP/phone-cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/phone- 
cisco-1-089a55d0]

No activity on the IAX side.

I've tried dtmfmode=rfc2833 in sip.conf to try to make sure the SIP  
side matches IAX's out of band, but no dice...

This has been happening since my change to 1.4.23 from 1.2.<i can't  
remember> so the upgrade is certainly the catalyst, but I can't figure  
out what has changed since 1.2 that is relevant to DTMF being received  
by a SIP channel not being transmitted out to an IAX channel.

Any pointers would be appreciated.