[asterisk-users] DTMF

[Anthony Francis]

Jeff LaCoursiere wrote:
> On Fri, 17 Apr 2009, Jeff LaCoursiere wrote:
>
>   
>> On Fri, 17 Apr 2009, Jeff LaCoursiere wrote:
>>
>>     
>>>> I went ahead and switched to SIP just for grins, and made sure
>>>> "dtmfmode=rfc2833" is in the peer config on both sides and in the entry
>>>> for the phone.  So now it is:
>>>>
>>>> polycom501---SIP/ulaw--->ast1---SIP/g729--->ast2---IAX/ulaw--->ITSP
>>>>         
>> A bit more information.  ast1 is running 1.4.23.1 and I noticed a debug line 
>> in rtp.c:
>>
>>        if (rtpdebug || option_debug > 2)
>>                ast_log(LOG_DEBUG, "- RTP 2833 Event: %08x (len = %d)\n", 
>> event, len);
>>
>> So I set debug to 10 and caught this line:
>>
>> [Apr 17 17:28:02] DEBUG[27264] rtp.c: - RTP 2833 Event: 00000002 (len = 4)
>>
>> So I guess that proves that from the phone to ast1 RFC2833 is in effect (I 
>> did actually press the digit '2', which I assume is the event code above?).
>>
>> I tried to do the same on ast2, which is running 1.4.22.1, and with debug set 
>> to 10 I did *not* get this message, which makes me think that RCF2833 is NOT 
>> in effect for the trunk between ast1 and ast2.  Is that reasonable?
>>
>>     
>
> The main problem turned out to be at my ITSP, and is now resolved.  The 
> question remains for me, though, how to interpret the debug lines I was 
> able to catch (or not) above.
>
> How do you really know if RFC2833 signalling is being received?  I caught 
> the debug message on ast1 but not on ast2.  I am using ulaw between ast2 
> and the ITSP, and I am now wondering if the DTMF is being sent inband on 
> that last leg since I could not catch the debug messages on ast2.  Perhaps 
> what they did to fix on their end is simply remove compression between 
> themselves and the PSTN.
>
> I would really like a concrete method of verifying that DTMF signalling is 
> being sent out of band on my outbound IAX link.  Any ideas?
>
> Thanks,
>
> j
>
>   
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