[Home]

Summary:ASTERISK-14003: Last digit missing when dialing out to pstn and echotraining=yes or echotraining=xx
Reporter:Rafael Angulo (rafuchoucv)Labels:
Date Opened:2009-04-22 19:25:42Date Closed:2011-06-07 14:08:06
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.


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

chan_dahdi.conf

[trunkgroups]
[channels]
context=from-pstn
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
;echocancel=yes
;echocancelwhenbridged=yes
;faxdetect=both
group=1
callgroup=1
pickupgroup=1
busydetect=yes
relaxdtmf=yes
;rxgain=14.0
;txgain=-6.0
rxgain=0.0
txgain=-7.0
inmediate=no
busycount=2
signalling=fxs_ks
language=es
echotraining=yes
;echotraining=800
channel => 1-2
inmediate=yes
signalling=fxo_ks
context=from-analogica
channel => 3
Comments:By: Rafael Angulo (rafuchoucv) 2009-04-22 19:33:15

I found that changing line 2674 in chan_dahdi.c from:
p->dop.dialstr[strlen(p->dop.dialstr)-2] = '\0';
to
p->dop.dialstr[strlen(p->dop.dialstr)-1] = '\0';
solved the problem, but I'm not shure why, can any guru around test it and confirm the bug and the solution?
By: Tzafrir Cohen (tzafrir) 2009-05-22 16:51:46

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.
By: Leif Madsen (lmadsen) 2009-09-18 08:54:39

I'm closing as it looks like tzafrir asked a bunch of questions, of which the reporter didn't respond back. If they are still interested in this issue, then feel free to reopen the issue and respond. Thanks!