[Home]

Summary:ASTERISK-09167: Channel DTMF stops taking new DTMF input. (Null Frame loop)
Reporter:Matthew Crawford (mcrawford)Labels:
Date Opened:2007-04-02 16:17:00Date Closed:2007-04-02 19:54:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax.conf
( 1) loadedmodulelist.txt
Description:
When using a IAX2 client the core receiving and processing of DTMF is unreliable at best. During a new session everything starts out fine. You send a DTMF tone and core processes it.

Rx-Frame Retry[ No] -- OSeqno: 009 ISeqno: 008 Type: DTMF_E  Subclass: 1
  Timestamp: 10763ms  SCall: 20857  DCall: 00002 [208.49.241.189:62726]
Tx-Frame Retry[-01] -- OSeqno: 008 ISeqno: 010 Type: IAX     Subclass: ACK    
  Timestamp: 10763ms  SCall: 00002  DCall: 20857 [208.49.241.189:62726]
<< [ TYPE: DTMF Begin (12) SUBCLASS: 1 (49) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [IAX2/6000-2]




Then after some use the Null Frame seems to become stuck in a loop that never exits:



Rx-Frame Retry[ No] -- OSeqno: 010 ISeqno: 008 Type: DTMF_E  Subclass: 1
  Timestamp: 11903ms  SCall: 20857  DCall: 00002 [208.49.241.189:62726]
Tx-Frame Retry[-01] -- OSeqno: 008 ISeqno: 011 Type: IAX     Subclass: ACK    
  Timestamp: 11903ms  SCall: 00002  DCall: 20857 [208.49.241.189:62726]
<< [ TYPE: DTMF Begin (12) SUBCLASS: 1 (49) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/6000-2]
(Will continue on forever)


At that point any further DTMF tones are just ignored. You can see the IAX RX and TX packet for the tone but the core debug will contain no indication that it knows the tone exists. From what I can tell because the previous DTMF did never end the future requests are either queued up or ignored all together.

I can generally cause the above loop to happen by sending a second DTMF request from the IAX client down before the first one completes. This will generally cause the loop.


****** ADDITIONAL INFORMATION ******


Asterisk: 1.4.2
IAX Client: Tested with JackenIAX and IDEFisk (Current Versions)
Destination: Extension 5000 (VoiceMailMain)
IAX Conf: Attached
Debug Level: 100
Comments:By: Joshua C. Colp (jcolp) 2007-04-02 18:21:24

Please try 1.4 from SVN, some fixes were put in specifically for this.
By: Matthew Crawford (mcrawford) 2007-04-02 19:52:14

Looks like the changes made for the latest SVN trunk did correct the problem. Was unable to duplicate the issue even with high speed rapid fire of dtmf. Looks good.

As this is a production system and this is dev release code is there any component area's under overhaul known to be unstable in the current SVN trunk?

Thanks!
By: Joshua C. Colp (jcolp) 2007-04-02 19:54:20

You should be using the 1.4 branch, http://svn.digium.com/svn/asterisk/branches/1.4, it is what becomes a release. It contains the latest bug fixes.