[asterisk-users] DTMF

[Jeff LaCoursiere]

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