Wrong zap channel problem - Help

Asterisk Asterisk Support
1

Hi, I have TDM404B card (4 FXO ports). I currently plug-in the phone line to port 4 only. When I made an outbound call, Asterisk actually used the port 1 to dial which is wrong. Please advise me if there could be anything wrong in my setup.

Below is from CLI

– Executing [4321108@numberplan-custom-1:1] Macro(“SIP/108-b5a11190”, “trunkdial|Zap/g1/4321108|”) in new stack
– Executing [s@macro-trunkdial:1] Set(“SIP/108-b5a11190”, “CALLERID(all)=”) in new stack
– Executing [s@macro-trunkdial:2] Dial(“SIP/108-b5a11190”, “Zap/g1/4321108”) in new stack
– Called g1/4321108
– Zap/1-1 answered SIP/108-b5a11190 <===!!! Note! It uses port 1 to dial but I have no phone line connect to this port.

When I run ztscan, it seems to be fine.

[root@asterisk asterisk]# ztscan
[1]
active=yes
alarms=OK
description=Wildcard TDM410P Board 1
name=WCTDM/0
manufacturer=Digium
devicetype=Wildcard TDM410P
location=PCI Bus 03 Slot 03
basechan=1
totchans=4
irq=18
type=analog
port=1,FXO
port=2,FXO
port=3,FXO
port=4,FXO

And my zapata.conf is like this
[trunk_1]
signalling = fxs_ks
callerid = asreceived
context = DID_trunk_1
canreinvite = no
group = 1
hasexten = no
hasiax = no
hassip = no
trunkname = Ports 1,2,3,4
trunkstyle = analog
zapchan = 1,2,3,4

And my zaptel.conf is like
[root@asterisk etc]# cat zaptel.conf
fxsks = 1,2,3,4
loadzone = us
defaultzone = us

2

Ah… there it is…

If you look at the output, you’ll see it says:

– Executing [s@macro-trunkdial:2] Dial(“SIP/108-b5a11190”, “Zap/g1/4321108”) in new stack

When using the dial command, you can change how the trunks are selected by using different names for the groups. You just need to change the group addressing a bit. Instead of dialing throught group g1, you should dial through G1. (Notice the “G” is capitalized.) Just change the group (in a global variable or in your macro) and it should work for you.

Of course, if you start a second call, the second call will attempt to use a trunk port that has no phone line. But the first call will go out through port number 4.

From the voip wiki:

[code]Dialing a Group
In the Zap Channel Module’s configuration file (zapata.conf), you can define groups of Zap channels that get treated as a single channel as far as the Dial command is concerned. You specify which of four methods the Zap channel module is to use to select a non-busy channel from the channel group by prefixing the group number with one of the letters g, G, r, or R:

g: select the lowest-numbered non-busy Zap channel (aka. ascending sequential hunt group).
G: select the highest-numbered non-busy Zap channel (aka. descending sequential hunt group).
r: use a round-robin search, starting at the next highest channel than last time (aka. ascending rotary hunt group).
R: use a round-robin search, starting at the next lowest channel than last time (aka. descending rotary hunt group).

The round-robin searches make the Zap channel module start looking for an available channel from a different channel number each time. For each channel group, the Zap channel module keeps track of the last round-robin start point, and this time starts checking availability from either the next (lowercase r)) or the previous uppercase R channel in the group. Which channel it actually finds available (if any) does not affect the starting point for the next round-robin search. Calls to the Dial command using ordinary (g or G) group selections do not affect future round-robin starting points either.

For example, if you have defined channel group 2 as containing Zap channels 1, 2, 5 and 8, and the last round-robin search for this group (group 2) began searching from channel 5, this is the order of searching that the Zap channel module will use for the four possible selection methods:

Dial(Zap/g2…): Looks in order 1, 2, 5, 8
Dial(Zap/G2…): Looks in order 8, 5, 2, 1
Dial(Zap/r2…): Looks in order 8, 1, 2, 5
Dial(Zap/R2…): Looks in order 2, 1, 8, 5 [/code]

Click here for more information:

voip-info.org/wiki/index.php … p+channels

3

Thanks for the reply. Appreciate.

But I am thinking in this case, even though I am using “g”, wouldn’t be Asterisk susposed to detect there is no phone line conncting to Port 1 and he should look for the next lowest non-busy and connected channel? So if Asterisk sees channel 1 is not connected, he should continue to look for channel 2, channel 3…

Thanks

4

No.

There is no detection method in the Zap cards that tells Asterisk if a line is connected or not.

It’s one of the reasons you might choose to use round-robin (“R1” or “r1”) trunk selection. If a trunk were out of service, and you had linear trunk selection configured, calls will continue to attempt to use the out of service trunk. Each time you redial, you’re call will try to use the out of service trunk. Calls will not try to use the next higher or lower trunk unless the out of service trunk is busy.

However, if you choose round-robin selection, the call may still attempt to use an out of service trunk, but the next call attempt will choose the next higher or the next lower trunk. This gives users a better chance to complete their call simply by redialing.

If you have round-robin selection, and 1 out of your 4 trunks is out of service, then every 4th call attempt will fail. However, you will compete the call when you redial.

If you use linear trunk selection, and say, the first trunk in the group is out of service, then every call attempt will fail. It would take an extremely careful timing event to complete a call, where one caller is trying to use the out of service trunk, and simultaneously, another call is placed. (The second call would hunt to an unused, but in service, trunk.)

5

I see. Many thanks for your explanation and suggestion. Will do that.

Many thanks again

6

dufus

You stated “There is no detection method in the Zap cards that tells Asterisk if a line is connected or not”

I noticed though that if you use zttool it will increment up or down the number of ports as you pull or plug a line in or out.

Is there not any work around in the dialout programming that would show the same and would try the next port.

If not, is the thinking that very seldom do individual pstn lines go out and not worth implementing.

thanks

7

Well, the zttool can show you such things. But it’s not something that works from within Asterisk.

If I were doing something like that, I’d work it into the Zap drivers. If there’s no line connected, it would report to the Asterisk software that the line was “busy” and why.

Right now however, it’s not something we have available.