Help with outbound route and the log while dialing

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#1
Hello,
I am gonna need some help, please.
The system is Elastix 2.0.3 it does have 1 Sangoma A102 connected with T1 crossover to a 3Com NBX.
I had created one trunk, on the trunk configuration page in the field:
"Zap Identifier (trunk name)" I had set only the number 1 (wanting to use the first zap channel). So I have:
Zap Identifier (trunk name):1
Is that correct trunk configuration?
The context for the channels is from-pstn, is that correct or I should change it to from-zaptel?
I had modified the default outbound route "9_outside" to use the trunk I created.
When I dial 92699 (2699 is extension in 3Com NBX) this is the log and I receive "all-circuits-busy-now".
Where I am wrong?

Could you read this log and tell what actually is going on, when I dial this number:
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Executing [2699@from-internal:1] Macro("SIP/1004-00000002", "user-callerid,SKIPTTL,") in new stack
-- Executing [s@macro-user-callerid:1] Set("SIP/1004-00000002", "AMPUSER=1004") in new stack
-- Executing [s@macro-user-callerid:2] GotoIf("SIP/1004-00000002", "0?report") in new stack
-- Executing [s@macro-user-callerid:3] ExecIf("SIP/1004-00000002", "1?Set(REALCALLERIDNUM=1004)") in new stack
-- Executing [s@macro-user-callerid:4] Set("SIP/1004-00000002", "AMPUSER=1004") in new stack
-- Executing [s@macro-user-callerid:5] Set("SIP/1004-00000002", "AMPUSERCIDNAME=LinksysPhone") in new stack
-- Executing [s@macro-user-callerid:6] GotoIf("SIP/1004-00000002", "0?report") in new stack
-- Executing [s@macro-user-callerid:7] Set("SIP/1004-00000002", "AMPUSERCID=1004") in new stack
-- Executing [s@macro-user-callerid:8] Set("SIP/1004-00000002", "CALLERID(all)="LinksysPhone" <1004>") in new stack
-- Executing [s@macro-user-callerid:9] ExecIf("SIP/1004-00000002", "0?Set(CHANNEL(language)=)") in new stack
-- Executing [s@macro-user-callerid:10] GotoIf("SIP/1004-00000002", "1?continue") in new stack
-- Goto (macro-user-callerid,s,19)
-- Executing [s@macro-user-callerid:19] NoOp("SIP/1004-00000002", "Using CallerID "LinksysPhone" <1004>") in new stack
-- Executing [2699@from-internal:2] Set("SIP/1004-00000002", "_NODEST=") in new stack
-- Executing [2699@from-internal:3] Macro("SIP/1004-00000002", "record-enable,1004,OUT,") in new stack
-- Executing [s@macro-record-enable:1] GotoIf("SIP/1004-00000002", "1?check") in new stack
-- Goto (macro-record-enable,s,4)
-- Executing [s@macro-record-enable:4] ExecIf("SIP/1004-00000002", "0?MacroExit()") in new stack
-- Executing [s@macro-record-enable:5] GotoIf("SIP/1004-00000002", "0?Group:OUT") in new stack
-- Goto (macro-record-enable,s,15)
-- Executing [s@macro-record-enable:15] GotoIf("SIP/1004-00000002", "0?IN") in new stack
-- Executing [s@macro-record-enable:16] ExecIf("SIP/1004-00000002", "1?MacroExit()") in new stack
-- Executing [2699@from-internal:4] Macro("SIP/1004-00000002", "dialout-trunk,2,2699,,") in new stack
-- Executing [s@macro-dialout-trunk:1] Set("SIP/1004-00000002", "DIAL_TRUNK=2") in new stack
-- Executing [s@macro-dialout-trunk:2] GosubIf("SIP/1004-00000002", "0?sub-pincheck,s,1") in new stack
-- Executing [s@macro-dialout-trunk:3] GotoIf("SIP/1004-00000002", "0?disabletrunk,1") in new stack
-- Executing [s@macro-dialout-trunk:4] Set("SIP/1004-00000002", "DIAL_NUMBER=2699") in new stack
-- Executing [s@macro-dialout-trunk:5] Set("SIP/1004-00000002", "DIAL_TRUNK_OPTIONS=tr") in new stack
-- Executing [s@macro-dialout-trunk:6] Set("SIP/1004-00000002", "OUTBOUND_GROUP=OUT_2") in new stack
-- Executing [s@macro-dialout-trunk:7] GotoIf("SIP/1004-00000002", "1?nomax") in new stack
-- Goto (macro-dialout-trunk,s,9)
-- Executing [s@macro-dialout-trunk:9] GotoIf("SIP/1004-00000002", "0?skipoutcid") in new stack
-- Executing [s@macro-dialout-trunk:10] Set("SIP/1004-00000002", "DIAL_TRUNK_OPTIONS=") in new stack
-- Executing [s@macro-dialout-trunk:11] Macro("SIP/1004-00000002", "outbound-callerid,2") in new stack
-- Executing [s@macro-outbound-callerid:1] ExecIf("SIP/1004-00000002", "0?Set(CALLERPRES()=)") in new stack
-- Executing [s@macro-outbound-callerid:2] ExecIf("SIP/1004-00000002", "0?Set(REALCALLERIDNUM=1004)") in new stack
-- Executing [s@macro-outbound-callerid:3] GotoIf("SIP/1004-00000002", "1?normcid") in new stack
-- Goto (macro-outbound-callerid,s,6)
-- Executing [s@macro-outbound-callerid:6] Set("SIP/1004-00000002", "USEROUTCID=") in new stack
-- Executing [s@macro-outbound-callerid:7] Set("SIP/1004-00000002", "EMERGENCYCID=") in new stack
-- Executing [s@macro-outbound-callerid:8] Set("SIP/1004-00000002", "TRUNKOUTCID=tr1") in new stack
-- Executing [s@macro-outbound-callerid:9] GotoIf("SIP/1004-00000002", "1?trunkcid") in new stack
-- Goto (macro-outbound-callerid,s,12)
-- Executing [s@macro-outbound-callerid:12] ExecIf("SIP/1004-00000002", "1?Set(CALLERID(all)=tr1)") in new stack
-- Executing [s@macro-outbound-callerid:13] ExecIf("SIP/1004-00000002", "0?Set(CALLERID(all)=)") in new stack
-- Executing [s@macro-outbound-callerid:14] ExecIf("SIP/1004-00000002", "0?Set(CALLERID(all)=)") in new stack
-- Executing [s@macro-outbound-callerid:15] ExecIf("SIP/1004-00000002", "0?Set(CALLERPRES()=prohib_passed_screen)") in new stack
-- Executing [s@macro-dialout-trunk:12] ExecIf("SIP/1004-00000002", "0?AGI(fixlocalprefix)") in new stack
-- Executing [s@macro-dialout-trunk:13] Set("SIP/1004-00000002", "OUTNUM=2699") in new stack
-- Executing [s@macro-dialout-trunk:14] Set("SIP/1004-00000002", "custom=DAHDI/1") in new stack
-- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/1004-00000002", "0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^))") in new stack
-- Executing [s@macro-dialout-trunk:16] Macro("SIP/1004-00000002", "dialout-trunk-predial-hook,") in new stack
-- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/1004-00000002", "") in new stack
-- Executing [s@macro-dialout-trunk:17] GotoIf("SIP/1004-00000002", "0?bypass,1") in new stack
-- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/1004-00000002", "0?customtrunk") in new stack
-- Executing [s@macro-dialout-trunk:19] Dial("SIP/1004-00000002", "DAHDI/1/2699,300,") in new stack
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [s@macro-dialout-trunk:20] NoOp("SIP/1004-00000002", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 0") in new stack
-- Executing [s@macro-dialout-trunk:21] Goto("SIP/1004-00000002", "s-CHANUNAVAIL,1") in new stack
-- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] Set("SIP/1004-00000002", "RC=0") in new stack
-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:2] Goto("SIP/1004-00000002", "0,1") in new stack
-- Goto (macro-dialout-trunk,0,1)
-- Executing [0@macro-dialout-trunk:1] Goto("SIP/1004-00000002", "continue,1") in new stack
-- Goto (macro-dialout-trunk,continue,1)
-- Executing [continue@macro-dialout-trunk:1] GotoIf("SIP/1004-00000002", "1?noreport") in new stack
-- Goto (macro-dialout-trunk,continue,3)
-- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/1004-00000002", "TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 0 - failing through to other trunks") in new stack
-- Executing [continue@macro-dialout-trunk:4] Set("SIP/1004-00000002", "CALLERID(number)=1004") in new stack
-- Executing [2699@from-internal:5] Macro("SIP/1004-00000002", "outisbusy,") in new stack
-- Executing [s@macro-outisbusy:1] Progress("SIP/1004-00000002", "") in new stack
-- Executing [s@macro-outisbusy:2] GotoIf("SIP/1004-00000002", "0?emergency,1") in new stack
-- Executing [s@macro-outisbusy:3] GotoIf("SIP/1004-00000002", "0?intracompany,1") in new stack
-- Executing [s@macro-outisbusy:4] Playback("SIP/1004-00000002", "all-circuits-busy-now&pls-try-call-later, noanswer") in new stack
-- <SIP/1004-00000002> Playing 'all-circuits-busy-now.gsm' (language 'en')
-- <SIP/1004-00000002> Playing 'pls-try-call-later.gsm' (language 'en')
== Spawn extension (macro-outisbusy, s, 4) exited non-zero on 'SIP/1004-00000002' in macro 'outisbusy'
== Spawn extension (from-internal, 2699, 5) exited non-zero on 'SIP/1004-00000002'
-- Executing [h@from-internal:1] Macro("SIP/1004-00000002", "hangupcall") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/1004-00000002", "1?noautomon") in new stack
-- Goto (macro-hangupcall,s,3)
-- Executing [s@macro-hangupcall:3] NoOp("SIP/1004-00000002", "TOUCH_MONITOR_OUTPUT=") in new stack
-- Executing [s@macro-hangupcall:4] GotoIf("SIP/1004-00000002", "1?noautomon2") in new stack
-- Goto (macro-hangupcall,s,6)
-- Executing [s@macro-hangupcall:6] NoOp("SIP/1004-00000002", "MONITOR_FILENAME=") in new stack
-- Executing [s@macro-hangupcall:7] GotoIf("SIP/1004-00000002", "1?skiprg") in new stack
-- Goto (macro-hangupcall,s,10)
-- Executing [s@macro-hangupcall:10] GotoIf("SIP/1004-00000002", "1?skipblkvm") in new stack
-- Goto (macro-hangupcall,s,13)
-- Executing [s@macro-hangupcall:13] GotoIf("SIP/1004-00000002", "1?theend") in new stack
-- Goto (macro-hangupcall,s,15)
-- Executing [s@macro-hangupcall:15] Hangup("SIP/1004-00000002", "") in new stack
== Spawn extension (macro-hangupcall, s, 15) exited non-zero on 'SIP/1004-00000002' in macro 'hangupcall'
== Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/1004-00000002'
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#2
What else I would like to verify with you is the file
dahdi-channels.conf

Can anybody answer why I do have two groups -
the top group=0,11
the bottom group = 63

thank you

; Span 1: WPT1/0 "wanpipe1 card 0" (MASTER) RED
group=0,11
context=from-pstn
switchtype = national
signalling = pri_cpe
channel => 1-23
context = default
group = 63

; Span 2: WPT1/1 "wanpipe2 card 1"
group=0,12
context=from-pstn
switchtype = national
signalling = pri_cpe
channel => 25-47
context = default
group = 63
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#3
Hello again,
this is what I think is the problem with outbound calls
Why the status is down and how I can bring it up?

The system logs this every 4 seconds:
[Dec 30 14:16:27] WARNING[3733] chan_dahdi.c: No D-channels available! Using Primary channel 24 as D-channel anyway!
[Dec 30 14:16:31] WARNING[3734] chan_dahdi.c: No D-channels available! Using Primary channel 48 as D-channel anyway!

elstx*CLI> pri show span 1
Primary D-channel: 24
Status: Provisioned, Down, Active
Switchtype: National ISDN
Type: CPE
Overlap Dial: 0
Logical Channel Mapping: 0
Timer and counter settings:
N200: 3
N202: 3
K: 7
T200: 1000
T202: 10000
T203: 10000
T303: 4000
T305: 30000
T308: 4000
T309: 6000
T313: 4000
T-HOLD: 4000
T-RETRIEVE: 4000
T-RESPONSE: 4000
Overlap Recv: No

Would appreciate any help,
Thank you.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
You will need to check with your provider, no D channel, No calls, end of story, maybe they need to "turn you up" on bothe T1's

dahdi_tool

will show whether the framing/line-coding are working
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#5
Yes, thanks. I checked with the provider - everything is turned up, in fact this is the same T1 circuit that used to be connected to the 3Com NBX. So it is known that both - T1 interface on NBX and the circuit are good.
Now when I have * between them, I D channels are down both with the provider and with NBX.
I am thinking to downgrade to Elastix 1.6 to see what will happen.
Also waiting support from Sangoma, hope that they could help too.
Would you give me some more details how to use dahdi_tool and how to analyze the results, please?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#6

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#7
Thank you for the suggestions. I followed the debugging procedures, with no success. Also the techsupport from Sangoma could not solve the issue after 3-4 hours work on the system. It turns to be weird problem. There is open circuit alarm on the first port that doesn't want to go away no matter what, I even moved the card to different PC, made another install - same issues. I start thinking that it is just bad hardware. Everything that I read about d channels unavailable is connected somehow with hardware and/or cable problems, the cabels I already tested. Will apreciate any other suggestions?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#8
If your "first port " is to the carrier, then you need to get them involved, If you are using pri-net signaling to your PBX, then that would be the source of your D channel, so your previous

[Dec 30 14:16:31] WARNING[3734] chan_dahdi.c: No D-channels available! Using Primary channel 48 as D-channel anyway!

is suspicious, are you sure your timing on span 2 is derived from the upline T1
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#9
This is the latest configuration of the ports that I have used.
Port 1 configured as w1g1 is connected to the "telco" and has those parameters:
T1
ESF,B8ZS
PRI_CPE
clocking = NORMAL

Port 2 configured as w2g1 is connected to the 3 Com NBX and has those parameters:
T1
ESF,B8ZS
PRI_NET
clocking = MASTER
reference clock port = 1

With this configuration I receive:
chan_dahdi.c: No D-channels available! Using Primary channel 24 as D-channel anyway!
chan_dahdi.c: No D-channels available! Using Primary channel 48 as D-channel anyway!
Port 1 is in open circuit alarm

But here is the deal. 3 Com NBX does have two T1 cards and both were connected to two circuits provided by the CO. One of these T1 circuits I have disconnected from 3ComNBX and connected to the Elastix box. Because these both T1 circuits are parts of the same trunk group on the CO side I asked them to shutdown the incoming calls on the T1 circuit that I am using now. What I asked from them is whenever a call arrives on the "testing" T1 the caller receives busy tone but I wanted the circuit alive with running D channel. They said that this is possible and will do it. That's why I think that I am connected and doing my test with valid T1 circuit. Yesterday I'd checked with their technician and he told me that "Yes, on their system D channel is turned up, all other chanels are turned off.
But they also see that in the circuit D channel is down" -do you think that this is possible and would I receive clocking(timing) in this case?
I assumed that on their side d channel is up, but the D channel is down because of the problems on my side - what do you think about this?
Now with you question you trow me again in doubts that I am using and testing using "dead" T1 circuit?
The problem is that would be very dificult to ask CO to bring up all the channels on the "testing" T1 because then many incoming calls will go "nowhere" and this is something I cannot afford.

What do you think?

Thank you for your help.

To answer to the question shortly - no, I am not sure that timing is derived from uplink T1. How I can make sure and check this?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#10
I'm sorry, I don't fully understand what you are saying, I suggest you find yourself a qualified engineer with a t-bert "T1 analyzer", she will be able to insert her equipment between you and your provider, and you and your equipment and almost immediately tell you you what you are doing wrong.

Your clocking source almost always needs to defer to your network clock source or bad things will happen
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#11
Will be done, thank you.
 

mihailenator@gmail.com

Joined
Dec 21, 2010
Messages
31
Likes
0
Points
0
#12
My issues with the channels have been solved. There was not only one problem, I am not going into the details for every one of them, just one to post something that may be useful for the others.
If in your chan_dahdi.conf file the text in red is missing (assuming you are using two ports sangoma T1 card):


;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2011-01-02
;Dahdi Channels Configurations
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no

;Sangoma A102 port 1 [slot:4 bus:13 span:1] <wanpipe1>
switchtype=national
context=from-pstn
group=0
echocancel=yes
signalling=pri_cpe
channel =>1-23

;Sangoma A102 port 2 [slot:4 bus:13 span:2] <wanpipe2>
switchtype=national
context=from-pstn
group=0
echocancel=yes
signalling=pri_net
channel =>25-47


Then you should use wancfg_dahdi instead of setup_sangoma to configure the channels.
This is what their support is saying:

So the issue here is that 'setup-sangoma' is actually broken for elastix ( I
had just found out). So I ran 'wancfg_dahdi' to setup the sangoma card. So I
did not really hand-edit anything. So for the future, if you require
re-configuration, run 'wancfg_dahdi". There is nothing else required to use
the channels. Just be aware of the group values in there for your outbound
calls, and adjust them accordingly
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,915
Messages
130,920
Members
17,595
Latest member
feparra121
Top