Zap - Auto Switch

Asterisk Asterisk Support
1

Hi all,
I have a small problem.
I have 2 TDM400 Card.
So I have 8 channels well configured. in my zapata.conf I created one group :

group = 1 channel => 1-8

In my extensions.conf I have something like :

... exten => _9.,2,Dial(Zap/g1/${EXTEN:1},25,t) ...

If, for example I have 3 lines availables, I put in Zap1, Zap2 and Zap3 it works perfectly, if the 1st is busy, it switch automatically to Zap2 or 3.
But if I put my 3 lines on Zap4, Zap5 and Zap6, It’ll hang on Zap1…

Is there a way to solve that please ???

Thank You

ps : sorry for my english !

2

i don’t think you should be specifying channels that don’t exist in the zapata.conf file. e.g. if you have channels 4, 5 and 6, you should say:

channel => 4-6

maybe?

3

Thanks for your reply,

But no, I have 8 channels, I mean, if one cable goes down, for example the one on the channel 6, that means that channel 6, 7 and 8 are down if I use Zap/g1…
If I use Zap/G1…, channel 6, 5, 4, 3, 2 and 1 are down !

THis is strange so I think I am missing something but I don’t know what !!!

4

Up -----

5

Ok… Zap channel group addressing works this way:

Use Dial(ZAP/g1) when you want the lowest numbered available channel to dial the call. (Linear ascending hunt)

exten => _9.,2,Dial(Zap/g1/${EXTEN:1},25,t)

Use Dial(ZAP/G1) when you want the highest numbered available channel to dial the call. (Linear descending hunt)

exten => _9.,2,Dial(Zap/G1/${EXTEN:1},25,t)

Use Dial(ZAP/r1) when you want the system to start at the lowest numbered available channel, and to go to the next numbered channel (ascending) for each new call. (Rotary ascending hunt)

exten => _9.,2,Dial(Zap/r1/${EXTEN:1},25,t)

Use Dial(ZAP/R1) when you want the system to start at the highest numbered available channel, and to go to the next lower numbered channel (descending) for each new call. (Rotary descending hunt)

exten => _9.,2,Dial(Zap/R1/${EXTEN:1},25,t)

What you’ll want to do is use the R or r method so that if a call fails, you can try again, and the next call will attempt to use the next trunk in the group. (Skipping the broken trunk.)

6

Ok I’ll try that !

But don’t you think that the same problem will happen ???
Or with a r or R it’ll skip it ?

Thank you

7

A call will still attempt to use the broken trunk.

However, unlike using the G or g method, the next call attempt will go to a different trunk. The trunk selection method for each new call is to pick the next trunk in the group, regardless of how many calls are in progress. Each new call attempt will try a different trunk.

Until you repair the broken trunk callers will still experience problems, however, with the G or g method, each new call attempt will continue to try the bad trunk as long as the trunks before it in the group remain active. This is the problem you are having.

The only really bad situation comes when the broken trunk is the only remaining trunk that is not in service. Then, of course, every call attempt will fail.

Try the R or the r method. It won’t fix the trunk, or take it out of service so callers won’t have any difficulty. But it will give the callers a way to avoid the broken trunk when they redial.

8

What about when the isdn cable is not connected?
When i connect my cable to 1-port (we have a 4-port BRI), the calls go in and out.
But when i connect the cable ony to port2 on the card…inbound calls work…but a cannot call outside

This is the error: (i tried with r1 and g1 option in dialplan, but no luck)
Must all the cables be connected, then it goes to other channels?

Nov 20 15:05:29 VERBOSE[5482] logger.c: – Hungup ‘Zap/1-1’
Nov 20 15:05:29 VERBOSE[5482] logger.c: == Everyone is busy/congested at this time (1:0/0/1)
Nov 20 15:05:29 DEBUG[5482] app_dial.c: Exiting with DIALSTATUS=CHANUNAVAIL.
Nov 20 15:05:29 VERBOSE[5482] logger.c: == Auto fallthrough, channel ‘SIP/2-081c5750’ status is ‘CHANUNAVAIL’
Nov 20 15:05:29 DEBUG[5482] channel.c: Spy MixMonitor removed from channel SIP/2-081c5750
Nov 20 15:05:29 DEBUG[5482] chan_sip.c: update_call_counter(2) - decrement call limit counter
Nov 20 15:05:29 VERBOSE[5483] logger.c: == End MixMonitor Recording SIP/2-081c5750
Nov 20 15:05:29 VERBOSE[5483] logger.c: == Executing [/usr/local/bin/postrecording asterisk-4432-1227189927.0]
Nov 20 15:05:29 DEBUG[4479] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_buddies WHERE name = ‘2’
Nov 20 15:05:29 DEBUG[4489] chan_sip.c: Stopping retransmission on ‘xayysvasxbivrdx@172.16.0.201’ of Response 582: Match Not Found
Nov 20 15:05:29 DEBUG[5482] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
Nov 20 15:05:29 DEBUG[5482] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield) VALUES (‘2008-11-20 15:05:27’,’“2” <2>’,‘2’,‘24216144’,‘default’, ‘SIP/2-081c5750’,‘Zap/1-1’,‘Dial’,‘Zap/r1/024216144’,2,0,‘NO ANSWER’,3,’’,‘asterisk-4432-1227189927.0’,’’)
Nov 20 15:05:29 DEBUG[4479] res_config_mysql.c: MySQL RealTime: Everything is fine.
Nov 20 15:05:29 VERBOSE[4479] logger.c: – SIP Seeding peer from astdb: ‘2’ at 2@172.16.0.201:5060 for 3600
Nov 20 15:05:29 DEBUG[4479] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_buddies WHERE name = '2’
Nov 20 15:05:29 DEBUG[4479] res_config_mysql.c: MySQL RealTime: Everything is fine.
Nov 20 15:05:29 VERBOSE[4479] logger.c: – SIP Seeding peer from astdb: ‘2’ at 2@172.16.0.201:5060 for 3600
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '“2” <2>'
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '2’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '24216144’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is 'default’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is 'SIP/2-081c5750’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is 'Zap/1-1’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is 'Dial’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is 'Zap/r1/024216144’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '2008-11-20 15:05:27’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '(null)'
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '2008-11-20 15:05:29’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '2’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is '0’
Nov 20 15:05:29 DEBUG[5482] pbx.c: Function result is ‘NO ANSWER’

9

First things first - ‘sebek72’ - this thread belongs to ‘MaKKrO’. Please start your own. Thank you :smile:.

MaKKrO - The system can’t tell if the analogue trunk is there or not - as there is no ‘are you there?’ type signalling going on (unlike ISDN).

I suppose you could incorporate some kind of ‘call failed’ test in your dialplan though.

“Nov 20 15:05:29 DEBUG[5482] app_dial.c: Exiting with DIALSTATUS=CHANUNAVAIL.” <— clue :wink:.

10

i wrote here because it’s a similar problem.
.
how do i incorporate the call fail test in my dialplan?

Thank you