[RESOLVED] - Outgoing Zap calls are being forced to busy!


#1

This is one of the strangest things I’ve ever seen.

We have a TDM400 with four FXO channels.

We have configured the dialplan such that a SIP user dials “9” followed by the outside number then hits send. The system seizes one of the FXO channels and dials the digits following the “9”.

We discovered that on almost every outgoing call, the central office was either returning slow busy signal or the call was directed immediately to the destination’s voicemail. We were able to confirm this time and time again by calling different destinations that we knew to be idle and either receiving slow busy signal or going directly to their voice mail.

As a debugging tool, we added to the dialplan extensions that let us access the FXO channels directly. After accessing an FXO channel, we dialed the outside number manually, and the problem never occured.

We returned to the problem scenario (dialing 9 and then the number) and listened in on the call from a POTS phone. We would hear a slight “click” as Asterisk seized the line. Then Asterisk dialed all but the last digit of the number. Then there a short period of silence, then a click, and finally Asterisk dialed the last digit. As before, the central office either returned slow busy signal or sent the call to voicemail (again, we confirmed that the destination was idle, and we used several destinations in our test).

I made an educated guess that the problem might be with this flag in zapata.conf;

echotraining=yes

So, I changed the flag to:

echotraining=no

Immediately, the problem improved. It still wasn’t 100%, but it was much better. We once again listened in on the call from a POTS phone. Now, we heard a slight “click” as Asterisk seized the line. Then Asterisk dialed ALL of the digits. There was no longer a short period of silence and a click between the next to last and last digits.

We were really having a hard time believing that there could even be a way to force a call directly to slow busy or voice mail, but we proceeded under that assumption.

As a further debugging test, we removed three of the FXO channels from the Asterisk Dial command. Immediately, the problem was gone and it worked 100% of the time. We then added a second channel to the Dial command, and it continued to work 100%. We added a third channel, and the problem re-appeared, but not very often. We added the fourth channel, and the problem occurs on about 50% of our calls.

Can anyone imagine what could be causing this? Thank you in advance for your efforts.

Here is the relevant information from zapata.conf, extensions,conf, zaptel.conf, and the Asterisk console output.

From zaptel.conf:

fxsks=1-4
loadzone = us
defaultzone=us

From zapata.conf:

[channels]

callwaiting=no ; We do not have call waiting.

echocancel=yes ; We do want to perform echo cancellation since these
echotraining=no ; are analog lines likely to have echo. If we set
; echotraining to yes, Asterisk sends a tone at the
; beginning of the conversation to speed up the task
; of learning the echo patterns so they can be cancelled.
; We tried this in the yes position for some time before
; we discovered that we were almost ALWAYS getting a
; busy signal or going directly to the destination’s
; voicemail. I don’t know why, but setting echo training
; to “no” reduced that problem.

context=Internal ; Ring-ins go to the Internal context
; in extensions.conf.

signalling=fxs_ks ; These are FXO loopstart lines, so we want them to use
; FXS loopstart signalling (the card needs to appear
; to the public network as if it is a phone). I have
; decided to use “kewlstart” instead of loopstart
; because the “experts” seem to favor it.

rxgain=15 ; This is the receive gain. The range is -100 to 100. ; A more positive number increases the volume of
; sound coming into the system. To test this,
; go to a terminal shell and type “ztmonitor 1 -v”.
; Then start a conversation on Zap/1 and monitor the
; receive level. Try to get it to average about 50%.
; If it is too, high, adjust this value up. If it is
; too low, adjust this value down.

txgain=15 ; This is the transmit gain. The range is -100 to 100.
; A more positive number increases the volume of
; sound going out of the system. To test this,
; go to a terminal shell and type “ztmonitor 1 -v”.
; Then start a conversation on Zap/1 and monitor the
; transmit level. Try to get it to average about 50%.
; If it is too, high, adjust this value up. If it is
; too low, adjust this value down.

channel => 1-4 ; This defines channels 1 through 4.

From extensions.conf

;
; The “General” category is for certain variables.
;
[general]
;
; If static is set to no, or omitted, then the pbx_config will rewrite
; this file when extensions are modified. Remember that all comments
; made in the file will be lost when that happens.
;
; XXX Not yet implemented XXX
;
static=yes
;
; if static=yes and writeprotect=no, you can save dialplan by
; CLI command ‘save dialplan’ too
;
; MATT - I changed writeprotect to yes. You must edit this file to change the dialplan.
writeprotect=yes

[globals]

; Create variables for the trunks.

Trunk1=Zap/1
Trunk2=Zap/2
Trunk3=Zap/3
Trunk4=Zap/4

; **************************************

; CONTEXT DEFINITION

; At first, we had one context for internal extensions, one for external, one for ring-ins,
; and one for outgoing calls. Upon further review, it makes more sense to have one, big
; context. We named it Internal because that was the name we used originally.

[Internal]

;********************************************************************************************

; Outgoing calls.

;********************************************************************************************

ignorepat => 9 ; When Asterisk is interpreting digits
; (such as during a transfer), this
; tells Asterisk to continue playing
; dialtone even after a ‘9’ is dialed.
;********************************************************************************************

; 9 followed by a number

exten => _9X.,1,Dial(${Trunk1}/w${EXTEN:1}&${Trunk2}/w${EXTEN:1}&${Trunk3}/w${EXTEN:1}&${Trunk4}/w${EXTEN:1},T)
; Dialing 9 followed by at least one
; digit causes us to seize one of the
; outbound trunks and dial all of the
; numbers following the leading 9.
; Note the “w” before the number to
; dial. We put this in because the
; FXO channels on the TDM400 were
; dialing the digits before the central
; office was returning dialtone (so
; leading digits were being lost).
; Each “w” causes the TDM400 to “wait”
; 1/2 second, so we put in a
; 1/2 second wait to prevent the
; problem.

exten => _9X.,2,Hangup() ; Always finish by hanging up.

exten => _9X.,102,congestion(5) ; All lines must be busy. Indicate
exten => _9x.,103,Hangup() ; congestion for 5 seconds then hangup.

Output from Asterisk console when dialing ‘96232188710’:

  • Executing Dial(“SIP/169-ed6f”, “Zap/1/w6232188710&Zap/2/w6232188710&Zap/3/w6232188710&Zap/4/w6232188710||T”) in new stack
    – Called 1/w6232188710
    – Called 2/w6232188710
    – Called 3/w6232188710
    – Called 4/w6232188710
    – Zap/1-1 answered SIP/169-ed6f
    – Hungup ‘Zap/4-1’
    – Hungup ‘Zap/3-1’
    – Hungup ‘Zap/2-1’

#2

We have found the issue. The problem was this command in the dialplan:

exten => _9X.,1,Dial(${Trunk1}/w${EXTEN:1}&${Trunk2}/w${EXTEN:1}&${Trunk3}/w${EXTEN:1}&${Trunk4}/w${EXTEN:1},T)

This command was telling each of the four channels to come off-hook and dial the number. Asterisk would then bridge the call to the channel that finished dialing first, and tell the other three channels to hang-up. With four calls coming in almost simultaneously, it’s not hard to see why the destination was almost always busy!

I changed the logic to below, and everything works now.

; **************************************

; This is the macro we use to make outgoing calls.
;
; ${ARG1} - Number to dial

[macro-OutgoingCall]

exten => s,1,Dial(${Trunk1}/w${ARG1},T) ; Start with trunk 1. If it is
exten => s,2,Hangup() ; in use, we will jump to step 102.
; Note the “w” before the number to
; dial. We put this in because the
; FXO channels on the TDM400 were
; dialing the digits before the central
; office was returning dialtone (so
; leading digits were being lost).
; Each “w” causes the TDM400 to “wait”
; 1/2 second, so we put in a
; 1/2 second wait to prevent the
; problem. We hangup at the conclusion
; of the call just to be safe.

exten => s,3,Dial(${Trunk2}/w${ARG1},T) ; Now use trunk 2. If it is
exten => s,4,Hangup() ; in use, we will jump to step 104.

exten => s,5,Dial(${Trunk3}/w${ARG1},T) ; Now use trunk 3. If it is
exten => s,6,Hangup() ; in use, we will jump to step 106.

exten => s,7,Dial(${Trunk4}/w${ARG1},T) ; Now use trunk 4. If it is
exten => s,8,Hangup() ; in use, we will jump to step 108.

exten => s,102,Goto(3) ; Trunk 1 was in use, try trunk 2.

exten => s,104,Goto(5) ; Trunk 2 was in use, try trunk 3.

exten => s,106,Goto(7) ; Trunk 3 was in use, try trunk 4.

exten => s,108,Congestion(5) ; All lines must be busy. Indicate
exten => s,109,Hangup() ; congestion for 5 seconds then hangup.

; **************************************

; CONTEXT DEFINITION

; At first, we had one context for internal extensions, one for external, one for ring-ins,
; and one for outgoing calls. Upon further review, it makes more sense to have one, big
; context. We named it Internal because that was the name we used originally.

[Internal]

;********************************************************************************************

; 9 followed by a number

exten => _9X.,1,Macro(OutgoingCall,${EXTEN:1})