[Home]

Summary:ASTERISK-14170: DAHDI takes considerably longer than Zaptel to complete call
Reporter:Danny Nicholas (sethsdad)Labels:
Date Opened:2009-05-19 13:59:40Date Closed:2011-06-07 14:07:26
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dahdi_prod.zip
( 1) dahdi_test.zip
Description:I'm actually on 1.4.25-rc1 on OpenSuse 11.0.  My test box is a Dell Poweredge 1550 and my production box is a Poweredge 1650.  test box uses TDM400P and prod box uses TDM410P.  Configuration was set up on test box then copied to prod box.  To make an outgoing call using the 1.4.21 release with Zaptel took 3-7 seconds.  On my test box, call takes about 8 seconds to connect.  on the production box, it takes 18-20 seconds.
Comments:By: Danny Nicholas (sethsdad) 2009-05-19 16:48:45

Adding ,,r to Dial minimizes the visibility of this problem.  Don't know if it actually reduces time to connect.
By: Leif Madsen (lmadsen) 2009-05-20 07:17:28

Can you test with everything the same except for Zaptel vs. DAHDI?

You're using two different versions of Asterisk, and I'd like to try and determine if the issue is with app_dial, or if it is really an issue with the channel drivers.
By: Danny Nicholas (sethsdad) 2009-05-20 08:24:15

Both releases are actually 1.4.25-rc1 - just wasn't available on drop-down for release selection.
By: Danny Nicholas (sethsdad) 2009-05-20 08:26:33

could actually be a chan_dahdi issue vs app_dial since this has no effect on SIP dialing.  Also, if I open the DAHDI channel "natively" [Dial(DAHDI/g1)]  I can dial out with no delay or interference.
By: Leif Madsen (lmadsen) 2009-05-20 08:53:39

Could you step back in DAHDI releases to see if it is a regression that has been introduced along the way?
By: Danny Nicholas (sethsdad) 2009-05-20 10:48:00

Ok - went to http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/
downloaded 2.1.0.4, 2.1.0.3, 2.1.0.2, 2.1.0.1, 2.1.0-rc5, 2.0.0 and 2.2.0-rc4.
Less than .3 second difference in the 2.1* and 2.0*;  2.2 locks up my machine.

I think we can safely rule out regression.
By: Danny Nicholas (sethsdad) 2009-05-20 10:53:47

here is my dialplan - anything dumb jump out??
By: Danny Nicholas (sethsdad) 2009-05-20 11:15:34

echotraining=no reduces time by about .5 seconds.
By: Danny Nicholas (sethsdad) 2009-05-20 11:18:30

dialplan snippets
[CallingRule_Local_7_digits]
exten => _XXXXXXX,1,Macro(trunkdial-failover-0.3,${trunk_1}/${DELAY}${EXTEN:0},,trunk_1,trunk_1)

trunk_1 => DAHDI/G1

[macro-trunkdial-failover-0.3]
exten = s,1,Set(CALLERID(num)=${IF($[${LEN(${CID_${CALLERID(num)}})} > 2]?${CID_${CALLERID(num)}}:)})
exten = s,n,GotoIf($[${LEN(${CALLERID(num)})} > 6]?1-dial,1)
exten = s,n,Set(CALLERID(all)=${IF($[${LEN(${CID_${ARG3}})} > 6]?${CID_${ARG3}}:${GLOBAL_OUTBOUNDCID})})
exten = s,n,Goto(1-dial,1)
exten = 1-dial,1,Dial(${ARG1},,r)
exten = 1-dial,n,Gotoif(${LEN(${ARG2})} > 0 ?1-${DIALSTATUS},1:1-out,1)
exten = 1-CHANUNAVAIL,1,Dial(${ARG2})
exten = 1-CHANUNAVAIL,n,Hangup()
exten = 1-CONGESTION,1,Dial(${ARG2})
exten = 1-CONGESTION,n,Hangup()
exten = 1-out,1,Hangup()
By: Grzegorz Garlewicz (garlew) 2009-05-20 12:39:58

try dialing natively through DAHDI/g1 and DAHDI/G1 (watch case sensitivity)
By: Danny Nicholas (sethsdad) 2009-05-20 13:00:44

That works fine - but how can I incorporate that into my dialplan.  My users don't want to dial 9 (or some other number), then dial at the dialtone.
By: Danny Nicholas (sethsdad) 2009-05-20 13:54:41

here's a strange note.  If I run Dial(DAHDI/G1/9www5551212) from my test box it works; won't on prod box.
By: Danny Nicholas (sethsdad) 2009-05-20 14:45:05

This is what I'm doing now
Dial(DAHDI/G1/5551212,,m) - when the connection is made. moh stops about 5-6 seconds after other end answers.

Downgraded libpri from 1.4.9 to 1.4.7


By: Dmitry Andrianov (dimas) 2009-05-21 09:20:47

have you tried callprogress=no ?
By: Danny Nicholas (sethsdad) 2009-05-21 09:30:33

Tried with yes and no.   With callprogress=no, dial(dahdi/g1/5551212) takes 22.5 seconds.  dial(dahdi/g1) enter 9 wait for dialtone, dial 5551212 takes 13.15 seconds.
By: Dmitry Andrianov (dimas) 2009-05-21 09:33:27

What you mean "dial(dahdi/g1) enter 9 wait for dialtone, dial 5551212 takes 13.15 seconds" ?

when you dial(dahdi/g1) you should get the dialtone immediately, right? (this should be true even if given FXO port is connected to some PBX)
By: Danny Nicholas (sethsdad) 2009-05-21 09:36:41

No. There is some sort of delay.  It takes from 1.4 to 1.9 seconds from entering 9 into my polycom 501 (press 9 then dial) to get an audible dialtone.  It might take that long to open the DAHDI/SIP channel for audio.
By: Dmitry Andrianov (dimas) 2009-05-21 09:39:52

What 9 are you talking about???
Can you just create some extension like 7777 which just dial(DAHDI/g1) and then use simple softphone to dial into this extension and see what happens?

You are stating the problem is with DAHDI but it obviously involves other pieces of your setup you did not mention at all...
By: Danny Nicholas (sethsdad) 2009-05-21 10:12:29

9 is my internal extension to do native DAHDI
exten => 9,1,Dial(DAHDI/G1)

This worked ok in 1.4.21 using Zaptel, so I'm thinking that the Polycom phone isn't the issue.

PS.  I'm working on the softphone, but have McAfee firewall, so that's another CAN-O-WORMS! (#!@#$@#$#$#@$#@$)
By: Dmitry Andrianov (dimas) 2009-05-21 10:28:54

Well, your "9" extension may just be a prefix for another extension so Asterisk won't execute Dial immediately as you press 9 (because it will be looking for more digits to check what extension you want to dial). With softphone you won't have this problem at all because as soon as you click "Call" button, Asterisk knows the whole number and does not wait for anything more.

If you really want to test the thing with analog phone, make you need to create and extension which you know for sure can not be a prefix of some other extension. Something like:

exten => 9#,1,Answer
exten => 9#,n,Dial(DAHDI/G1)

and look at Asterisk console - as soon as you hit # after 9, it should _immediately_ execute Answer+Dial.
By: Danny Nicholas (sethsdad) 2009-05-21 10:42:10

Ok.  I set up the 9# in the dialplan as you suggested.  I set my verbosity to 20 to make sure I got all messages.  When I punch in 9# and hit Dial (my Polycom doesn't send on #), I get the messages immediately, but it takes 1-2 seconds to get a dialtone.

When I call an automated number, it takes 8.5 seconds from start to connect with manual dial, 18.5 doing auto dial XXXXXXX#
By: Dmitry Andrianov (dimas) 2009-05-21 10:43:51

Ghm... It looks like Polycom 501 is an IP phone not analog one. Which means you do not need to worry about softphone.
You should have CALL/DIAL button on your phone which will make it sending the digits you dialed so far to Asterisk. So create

exten => 9,1,Answer
exten => 9,n,Dial(DAHDI/G1)

dial 9 and press Dial. Watch the Asterisk console - make sure the Anserw+Dial will be executed immediately. How many seconds passes before you hear the dialtone?
By: Dmitry Andrianov (dimas) 2009-05-21 10:47:12

Sorry about the # stuff - I was under impression you are using analog phone to initiate the call.

So you are saying Dial(DAHDI/G1) gives you dialtone in 1-2 seconds,
if you enter digits using your Polycom phone, what happens after the last digit is entered? How many seconds before you will hear ringing?
By: Danny Nicholas (sethsdad) 2009-05-21 10:52:02

1.4 - 1.9 seconds.  Once I enter the number, switching takes 5-6 seconds manually or 15-20 seconds under app_dial control.  

The console message are immediate, but sound is delayed.


By: Dmitry Andrianov (dimas) 2009-05-21 11:14:48

Well, honestly I'm not sure but the toneduration=1000 looks too much for me - it means every digit takes 1 second to be dialed.
By: Danny Nicholas (sethsdad) 2009-05-21 11:28:19

I think you're barking up the right tree here.  Changing value to 100 cut the dial/connect time to under 8 seconds.  Still takes about 1-2 seconds to get dial tone on manual dial, but much more joy.
By: Dmitry Andrianov (dimas) 2009-05-21 13:13:40

Well, I do not know where Asterisk spends time when it needs to dial out :) but if I were you, I would start with disabling everything like echo training (should give you about a sec).

Also, toneduration=100 may be long enough too - becaue 80 is well within the standard.
By: Dmitry Andrianov (dimas) 2009-05-21 13:28:13

... and do not forget setting call progres to no as well..
By: Danny Nicholas (sethsdad) 2009-05-21 14:00:05

dimas, You're the man!!! with td=80 and cp=no, I'm now getting calls completed as quickly or better than with Zaptel.  Now if you could just get them to address the issue where DAHDI doesn't check analog lines for status before running playback...

We can mark this one as closed.
By: Leif Madsen (lmadsen) 2009-05-22 06:37:09

Is the toneduration=1000 the default? Or was that manually set?
By: Dmitry Andrianov (dimas) 2009-05-22 06:48:21

It was definitely set either manually or with some tool. The sample config contains:

; How long generated tones (DTMF and MF) will be played on the channel
; (in milliseconds)
;toneduration=100

(commented out) so the DAHDI driver default is used which is also 100 ms...
By: Grzegorz Garlewicz (garlew) 2009-05-22 07:15:50

drivers/dahdi/dahdi-base.c:

static struct dahdi_dialparams global_dialparams = {
   .dtmf_tonelen = DEFAULT_DTMF_LENGTH,
   .mfv1_tonelen = DEFAULT_MFR1_LENGTH,
   .mfr2_tonelen = DEFAULT_MFR2_LENGTH,
};



drivers/dahdi/digits.h:

#define DEFAULT_DTMF_LENGTH 100 * DAHDI_CHUNKSIZE


am I wrong or it defaults to 800?
By: Dmitry Andrianov (dimas) 2009-05-22 07:20:14

it is in samples initially not in milliseconds. But if you use toneduration options in the config file, you are setting value in milliseconds.
That is not very consistent so I already filled another issue yesterday - https://issues.asterisk.org/view.php?id=15173
By: Leif Madsen (lmadsen) 2009-05-22 07:49:00

Closing this issue. No change required.