I am running the Asterisk Business Edition C, and we are unable to dial FreeConference.com numbers based in MN. We dial out all day long distance both domestic and international, but cannot dial 218-862-xxxx. It results in a fast busy signal. We are using a TDM800P FXO with PSTN lines, as well as Voicepulse (SIP) for making and receiving calls.
I disconnected one of the PSTN lines and attached a standard analoge phone, and was able to dial the number without a problem, but when I dial out through the asterisk box, the call results in a fast busy signal.
Verbosity is at least 15
– Executing [91218862xxxx@DLPN_Default:1] Macro(“SIP/75241-09734788”, “trunkdial-failover-0.3|DAHDI/trunk_3/1218862xxxx|SIP/trunk_1/12188621300|trunk_3|trunk_1”) in new stack
– Executing [s@macro-trunkdial-failover-0.3:1] GotoIf(“SIP/75241-09734788”, “0?1-fmsetcid|1”) in new stack
– Executing [s@macro-trunkdial-failover-0.3:2] GotoIf(“SIP/75241-09734788”, “1?1-setgbobname|1”) in new stack
– Goto (macro-trunkdial-failover-0.3,1-setgbobname,1)
– Executing [1-setgbobname@macro-trunkdial-failover-0.3:1] Set(“SIP/75241-09734788”, “CALLERID(name)=MyCorp”) in new stack
– Executing [1-setgbobname@macro-trunkdial-failover-0.3:2] Goto(“SIP/75241-09734788”, “s|3”) in new stack
– Goto (macro-trunkdial-failover-0.3,s,3)
– Executing [s@macro-trunkdial-failover-0.3:3] Set(“SIP/75241-09734788”, “CALLERID(num)=7524”) in new stack
– Executing [s@macro-trunkdial-failover-0.3:4] GotoIf(“SIP/75241-09734788”, “0?1-dial|1”) in new stack
– Executing [s@macro-trunkdial-failover-0.3:5] Set(“SIP/75241-09734788”, “CALLERID(all)=864-329-xxxx”) in new stack
– Executing [s@macro-trunkdial-failover-0.3:6] Goto(“SIP/75241-09734788”, “1-dial|1”) in new stack
– Goto (macro-trunkdial-failover-0.3,1-dial,1)
– Executing [1-dial@macro-trunkdial-failover-0.3:1] Dial(“SIP/75241-09734788”, “DAHDI/trunk_3/1218862xxx”) in new stack
[Feb 13 08:18:35] WARNING[28004]: chan_dahdi.c:8811 dahdi_request: Unable to determine channel for data trunk_3/1218862xxxx
[Feb 13 08:18:35] WARNING[28004]: app_dial.c:1355 dial_exec_full: Unable to create channel of type ‘DAHDI’ (cause 0 - Unknown)
== Everyone is busy/congested at this time (1:0/0/1)
– Executing [1-dial@macro-trunkdial-failover-0.3:2] GotoIf(“SIP/75241-09734788”, “23 > 0 ?1-CHANUNAVAIL|1:1-out|1”) in new stack
– Goto (macro-trunkdial-failover-0.3,1-CHANUNAVAIL,1)
– Executing [1-CHANUNAVAIL@macro-trunkdial-failover-0.3:1] Dial(“SIP/75241-09734788”, “SIP/trunk_1/1218862xxxx”) in new stack
– Called trunk_1/12188621300
– Got SIP response 503 “Service Unavailable” back from 64.61.93.190
– SIP/trunk_1-0970b1e8 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Executing [1-CHANUNAVAIL@macro-trunkdial-failover-0.3:2] Hangup(“SIP/75241-09734788”, “”) in new stack
== Spawn extension (macro-trunkdial-failover-0.3, 1-CHANUNAVAIL, 2) exited non-zero on ‘SIP/75241-09734788’ in macro ‘trunkdial-failover-0.3’
== Spawn extension (DLPN_Default, 912188621300, 1) exited non-zero on ‘SIP/75241-09734788’
Notes: I have changed the caller id information, and the true phone number being dialed using xxxx as the last four digits.
Yes, I am using a TDM (DAHDI), which errors out for some unknown reason, and then the call fails over to a SIP trunk, via VoicePulse, and errors out again, if I am reading this correctly. What I can’t seem to get my hands around is that we can call out to other numbers fitting the (_91NXXXXXXXXX) dial pattern, but not 1-218-862-xxxx.
[quote]-- Executing [1-dial@macro-trunkdial-failover-0.3:1] Dial(“SIP/75241-09734788”, “DAHDI/trunk_3/1218862xxx”) in new stack
[Feb 13 08:18:35] WARNING[28004]: chan_dahdi.c:8811 dahdi_request: Unable to determine channel for data trunk_3/1218862xxxx
[Feb 13 08:18:35] WARNING[28004]: app_dial.c:1355 dial_exec_full: Unable to create channel of type ‘DAHDI’ (cause 0 - Unknown)[/quote]
Is there a better way to a better log of the situation?
Can you confirm that the calls that work are going out the DAHDI trunk?
Perhaps none of the calls are going out the DAHDI lines and your VoIP provider has ha problem with the MN numbers.