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. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
