search for: ast_rtp_dtmf

...w would I debug RTP/DTMF on the new ast 1.8 server and see > if the SRCC is changing between my scenarios described above.? Am I on the > right track or is there something else I should be looking at? > I added [96] in */main/rtp.c of the ast 1.4 servers then recompiled. [96] = {0, AST_RTP_DTMF}, [97] = {1, AST_FORMAT_ILBC}, [99] = {1, AST_FORMAT_H264}, [101] = {0, AST_RTP_DTMF}, This seemed to allow flow through of the DTMF up to the new 1.8 call servers and on to the carrier. I don't know why this seemed to fix the issue, I'm not 100% convinced it really...

...39648000]: rtp.c:418 ast_rtp_read: Unknown RTP codec 96 received May 5 10:48:15 NOTICE[139648000]: rtp.c:418 ast_rtp_read: Unknown RTP codec 96 received We had this static_RTP_PT[xx] structure in rtp.c :(asterisk source): [...] [34] = {1, AST_FORMAT_H263}, [97] = {1, AST_FORMAT_ILBC}, [101] = {0, AST_RTP_DTMF}, [110] = {1, AST_FORMAT_SPEEX}, [121] = {0, AST_RTP_CISCO_DTMF}, // Must be type 121 [...] as there is no 96 entry and function ast_rtp_read() is returning 'Unknown RTP.....". We added entry, recompiled Asterisk and yeah it works!!!!!! See debug below: [...] Answering with preferred ca...

..., but my production system didn't. I debugged the RTP and captured the DTMF tones between the working and not working setup and noticed the production system was sending DTMF codec number [96] and the lab system was sending DTMF codec number [101]. This was a result of adding "[96] = {0, AST_RTP_DTMF}," to rtp.c in effort to resolve errors I was getting when passing calls to a cisco call manager. The errors went away, but now sends an invalid codec number to the 2600 gateway, which drops the call. I took out that codec number in rtp.c, recompiled and DTMF works fine now. I'm sure my...