[asterisk-bugs] [Asterisk 0014953]: Last digit missing when dialing out to pstn and echotraining=yes or echotraining=xx

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14953 
====================================================================== 
Reported By:                rafuchoucv
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14953
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.7 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-04-22 19:25 CDT
Last Modified:              2009-05-22 16:51 CDT
====================================================================== 
Summary:                    Last digit missing when dialing out to pstn and
echotraining=yes or echotraining=xx
Description: 
In asterisk 1.6.0.9 and dahdi 2.1.0.4 after I activated echotraining=yes,
calls to pstn through a Digium TDM400P failed because the last digit of the
number I dialed was not send, I can't even hear the busy tone produced by
the wrong number dialed. echocancel parameter does not make any diference
Commenting out echotraining=yes solved the problem, but i need
echotraining.

The log shows:

[Apr 22 19:30:58] DEBUG[5110] chan_dahdi.c: Dialing '04141060473'
[Apr 22 19:30:58] DEBUG[5110] chan_dahdi.c: Deferring dialing...
[Apr 22 19:30:58] DEBUG[5110] devicestate.c: Notification of state change
to be queued on device/channel DAHDI/1
[Apr 22 19:30:58] VERBOSE[5110] logger.c:     -- Called 1/04141060473
[Apr 22 19:30:58] DEBUG[5062] devicestate.c: Changing state for DAHDI/1 -
state 2 (In use)
[Apr 22 19:30:58] DEBUG[5073] app_queue.c: Device 'DAHDI/1' changed to
state '2' (In use) but we don't care because they're not a member of any
queue.
[Apr 22 19:30:58] DEBUG[5110] channel.c: Set channel DAHDI/1-1 to read
format gsm
[Apr 22 19:30:58] DEBUG[5110] channel.c: Set channel SIP/dfreepbx-01a081a0
to read format slin
[Apr 22 19:30:58] DEBUG[5110] channel.c: Set channel DAHDI/1-1 to write
format slin
[Apr 22 19:30:59] DEBUG[5110] chan_dahdi.c: Exception on 15, channel 1
[Apr 22 19:30:59] DEBUG[5110] chan_dahdi.c: Got event Hook Transition
Complete(12) on channel 1 (index 0)
[Apr 22 19:30:59] DEBUG[5110] chan_dahdi.c: Sent deferred digit string:
T0414106047

at the end is the number with the last digit stripped.

====================================================================== 

---------------------------------------------------------------------- 
 (0105338) tzafrir (manager) - 2009-05-22 16:51
 https://issues.asterisk.org/view.php?id=14953#c105338 
---------------------------------------------------------------------- 
Hi, thanks for your report!

However your patch only cures the symptom. The code you patched is
intended to cut off the last digit from the dial string in case echo
training is used.

The code there sets echobreak. echobreak is tested when the driver
finishes dialing that string and sends up a DAHDI_EVENT_COOMPLETE event.

If all goes well, you should see in a debug trace that event recieved and
then immediately after that the last digit sent. After the last digit is
sent, you'll also get a DAHDI_EVENT_COMPLETE, of course, but then nothing
will follow.

Which of the above actually happens?

Note that this should happen just the same even with your patched code, as
you have not modified the setting of echorest and echobreak, and from the
fact that your patch has effect, we know that the code that sets those two
was reached. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-22 16:51 tzafrir        Note Added: 0105338                          
======================================================================