[asterisk-users] DTMF not being sent ( RFC2833 )

Sun Apr 24 11:13:14 CDT 2011

Hello,

I traced the SIP packets and saw that the only difference was that the 
DAHDI channel returns 183 Session progress ( besides the obvious 
differences such as the To and from tags in sip , session id and rtp 
ports in the SDP ).

I updated my dialplan on asterisk-pri as follows :

exten => 6,1,Progress
exten => 6,n,Wait(5)
exten => 6,n,Answer
exten => 6,n,Wait(30)

This makes the local channel behave the same as the DAHDI channel. With 
this in place, the SIP packets for both test calls are identical ( 
excluding the To header, To Tag, From Tag, SDP ports, SDP session Id and 
SDP version.

Everything else is identical. So the problem appears to be caused in the 
RTP and not in the SIP. So something about the RTP packets coming from 
the DAHDI channel on asterisk-pri makes asterisk server send invalid DTMF.

David

On 11-04-24 11:42 AM, David wrote:
> I did more testing.
>
> Here is a portion of extensions.conf on asterisk-pri:
>
> exten => 5,1,Dial(DAHDI/g1/14186939930,30)
> exten => 6,1,Answer
> exten => 6,2,Wait(30)
> exten => 7,1,Dial(DAHDI/g1/14186939930,30,D(132412983#))
>
> Here is an expert from asterisk :
>
> exten => 22,1,Dial(SIP/6 at pri,30,D(132412983#))
> exten => 24,1,Dial(SIP/5 at pri,30,D(132412983#))
>
> If I type "console dial 24", the DTMFs work poorly, and I see messages 
> like :
>
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2907 __ast_read: DTMF end 
> emulation of '1' queued on DAHDI/1-1
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
> received on SIP/omnity-00000004, duration 60120 ms
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
> accepted with begin '1' on SIP/omnity-00000004
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2858 __ast_read: DTMF end 
> passthrough '1' on SIP/omnity-00000004
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2874 __ast_read: DTMF begin 
> '1' received on DAHDI/1-1
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2884 __ast_read: DTMF begin 
> passthrough '1' on DAHDI/1-1
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
> received on DAHDI/1-1, duration 39 ms
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
> accepted with begin '1' on DAHDI/1-1
> [Apr 24 11:26:20] DTMF[2691]: channel.c:2851 __ast_read: DTMF end '1' 
> has duration 39 but want minimum 80, emulating on DAHDI/1-1
>
> If I type console dial 22 on asterisk, all the DTMFs are 60ms in 
> length and I get no unusually long DTMFs.
>
> If I type console dial 7 on asterisk-pri, all the DTMFs are properly 
> sent, and the remote party sees my DTMFs perfectly.
>
> So it would seem that the bug occurs when one asterisk calls the 
> second asterisk which bridges to a DAHDI channel.
>
> My next step is too compare the SIP signalling between the two calls. 
> Maybe something is different.
>
> What I find really weird is that the DTMF is incorrectly sent from the 
> first asterisk only when the second asterisk bridges to DAHDI.
>
> Any ideas?
>
> David
>
> On 11-04-23 11:48 AM, David wrote:
>> Hello,
>> I installed Asterisk 1.6.2.17.3 ( latest as of yesterday ) and had 
>> multiple problems with DTMF.
>> I have two machines, we'll call them asterisk and asterisk-pri. 
>> Asterisk does IVR and asterisk-pri has a PRI card in it and connects 
>> to the PSTN. The two servers communicate via SIP with RFC2833.
>> I setup logger.conf on both machines to display DTMF to the console. 
>> Both are built from source.
>> Asterisk : spandsp, dahdi, asterisk.
>> Asterisk-pri : spandsp, libpri, dahdi, asterisk wanpipe
>> I eliminated AGI, hard phones, network et al by setting up this 
>> extension :
>> exten => 22,1,Dial(SIP/114186939930 at pri1.omnity.net,30,D(132412983 
>> <mailto:SIP/114186939930 at pri1.omnity.net,30,D%28132412983>#))
>> in default.
>> The only other non default setting is in sip.conf I added a 
>> outboundproxy ( which does NOT do RTP, only SIP ).
>> I called asterisk from my hard phone ( gxp2000 ) by dialing 22.
>> I see the console DTMF messages indicating the DTMF was sent or 
>> received. ( I forgot to keep this output ).
>> I than watch the console DTMF output on asterisk-pri and it showed 
>> about half the DTMFs. The pager that was called showed the DTMFs that 
>> appeared on the asterisk-pri console.
>> So somewhere between the two machines, the DTMFs have disappeared. So 
>> I ran TCPDump on asterisk and saw that close to half of the DTMF 
>> events were never sent.
>> tcpdump -i eth0 -n -s 0 dst asterisk-pri-ip -vvv -w ~/dtmf.pcap
>> I imported the file into wireshark on my local machine and confirmed 
>> that the dump almost matches what I saw on asterisk-pri.
>> So, problem 1 : Asterisk is not sending all the DTMFs to asterisk-pri.
>> I compared the packet scan to what I saw on asterisk-pri and noticed 
>> that between 1 and 3 dtmfs were missing.
>> Problem 2 : Asterisk-pri loses some received DTMFs.
>> I also noticed that some of the DTMFs coming out of asterisk had the 
>> wrong Event Duration. I had one DTMF with a duration of about 58000 ( 
>> I believe that's 58 seconds ) but I only pressed the button for like 
>> 1/3 of a second.
>> What I do not understand is that I in my final test last night was 
>> using asterisk 1.6 current with centos ( os that asterisk is 
>> developed on from my understanding ) with all default settings ( 
>> excluding logger.conf, dialplan and outboundproxy ) and I am having 
>> problems with the DTMF.
>> Both servers were installed with CentOS 5.5 and were updated last 
>> night, after which I reinstalled asterisk. This did not resolve the 
>> issue.
>> I am at wit's end and do not know where to go from here. I would 
>> really appreciate it if someone could give me some pointers on where 
>> to go next, what additionnal debugging steps I should perform. I 
>> would also really appreciate if someone could propose a solution.
>> Please help!
>> David
>> Never give up, never surrender
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>                 http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>     http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                 http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110424/9e25459f/attachment.htm>