[asterisk-users] DTMF

[Anthony Francis]

Anthony Francis wrote:
> 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
>   

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.