[Home]

Summary:ASTERISK-09335: DTMF tones get stuck on when passed through agent channel which is running on a zap channel
Reporter:James Terhune (bigjimmy)Labels:
Date Opened:2007-04-27 12:24:39Date Closed:2007-07-09 21:20:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast-1.4-stfu-dtmf-generator.patch
Description:We have an agent who is logged in through a Zap channel and is bridged and talking to a client on another channel.  The client for some reason presses a DTMF key on their phone, the agent then hears a continuous DTMF tone until they hangup their phone, or AgentLogoff is called.

From what I can tell, it's generating the tone from within main/channel.c (in ast_senddigit_begin) function.  For some reason, the ast_senddigit_end function never gets called (possibly because the tone that's being generated is looping back and getting detected again).

I have attached a patch that stops the generation of the tone after 100ms.  This doesn't actually fix the problem, but it stops the DTMF tones after 100ms.  The problem exists in Asterisk 1.4.x, SVN trunk, but not 1.2.X.

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

To reproduce the problem, you need a Zap channel and another phone (doesn't have to be on a Zap channel) with the following in the dialplan:

exten => 0,1,AgentLogin()
exten => _4XXX,1,Dial(Agent/${MATH(${EXTEN}-4000,i)})

Get the zap phone to dial 0 and the other one to dial 4001 (assuming you logged in as agent #1).  Once they are connected, press any DTMF key on the other phone.
Comments:By: jiddings (jiddings) 2007-04-27 12:37:47

http://bugs.digium.com/view.php?id=9615

Wow, go figure we'd both report the same bug within a few minutes of each other.

Just wanted to relay the fact that it's not just happening on Zap channels. I will test your patch however and let you know.
By: dea (dea) 2007-04-27 12:51:45

Likely related http://bugs.digium.com/view.php?id=9596

Most probable culprit is Russell's recent work on DTMF
duration enforcement....

The patch does not help the skinny case, but I think I see the issue.

In main/channel.c line ~2303:

if (!f->len)
   f->len = ast_tvdiff_ms(now, chan->dtmf_tv);
ast_verbose("f->len is %ld\n", f->len);  /* Added by DEA for testing */
if (f->len < AST_MIN_DTMF_DURATION) {
  ast_set_flag(chan, AST_FLAG_EMULATE_DTMF);
  chan->emulate_dtmf_digit = f->subclass;
  chan->emulate_dtmf_duration = AST_MIN_DTMF_DURATION - f->len;
  f = &ast_null_frame;
} else
   chan->dtmf_tv = now;
ast_verbose("f->len is %ld\n", f->len);  /* Added by DEA for testing */

The frame length is always 0 at the first ast_verbose for the first
digit.  It remains 0 at the second ast_verbose

The test to clear AST_FLAG_EMULATE_DTMF depends on chan->emulate_dtmf_duration
being 0, but this code:
  chan->emulate_dtmf_duration = AST_MIN_DTMF_DURATION - f->len;

Translates nicely into:
  chan->emulate_dtmf_duration = 45 - 0;

And we have never-ending DTMF....


By: jiddings (jiddings) 2007-04-27 12:55:39

The above patch solves my problem too.. thanks so much! :)
By: James Terhune (bigjimmy) 2007-04-27 13:59:50

I don't think it's related to ASTERISK-9315 as this problem goes all the way back to 1.4.0 and I believe it was caused by them going from a singular ast_senddigit to ast_senddigit_begin followed by ast_senddigit_end.

And I did check to make sure the issue wasn't already in the tracker before I posted, it just took me a while to type it all out :-)
By: Russell Bryant (russell) 2007-04-27 16:11:40

This issue has been resolved in 1.4 and trunk in revisions 62218 and 62219.  Thanks!