[asterisk-users] DTMF
Jason Lixfeld
jason+lists.asterisk at lixfeld.ca
Tue Apr 21 12:34:09 CDT 2009
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.
More information about the asterisk-users
mailing list