Issue Dialing Out

Home » Asterisk Users » Issue Dialing Out
Asterisk Users 7 Comments

Hello all.

I’m having trouble resolving an issue with our Asterisk system that seems to have popped up recently (no one knows for sure when the issue started). I’m still somewhat of a Asterisk newb and have been tasked with administrating the system as the previous administrator has left the company.

Within asterisk, we have a Zap interface setup connected to a PRI that we have through a telco. We have a certain extension setup to forward to a users cellphone when the extension is dialed. This apparently is no longer working, an we receive the following message when dialing the extension:

“The number you have dialed cannot be reached by the long-distance company you’ve selected. Please check the code and dial again, or call your long-distance company for assistance. P-U-A-M-I-2-3”

This is what I see in the logs when this issue occurs (actual numbers redacted):

Jun 15 13:05:59 VERBOSE[30232]: — Executing Answer(“Zap/1-1”, “”) in new stack Jun 15 13:05:59 VERBOSE[30232]: — Executing Wait(“Zap/1-1”, “2”) in new stack Jun 15 13:06:01 VERBOSE[30232]: — Executing Goto(“Zap/1-1”,
“pri-in-dids|XXXXXX3730|1”) in new stack Jun 15 13:06:01 VERBOSE[30232]: — Goto (pri-in-dids,XXXXXX3730,1)
Jun 15 13:06:01 VERBOSE[30232]: — Executing Goto(“Zap/1-1”,
“menu-v2|s|1”) in new stack Jun 15 13:06:01 VERBOSE[30232]: — Goto (menu-v2,s,1)
Jun 15 13:06:01 VERBOSE[30232]: — Executing BackGround(“Zap/1-1”,
“firstintro”) in new stack Jun 15 13:06:01 VERBOSE[30232]: — Playing ‘firstintro’ (language ‘en’)
Jun 15 13:06:05 VERBOSE[30232]: == CDR updated on Zap/1-1
Jun 15 13:06:05 VERBOSE[30232]: — Executing Dial(“Zap/1-1”,
“zap/g1/1XXXXXX2222|20|tT”) in new stack Jun 15 13:06:05 VERBOSE[30232]: — Called g1/1XXXXXX2222
Jun 15 13:06:08 VERBOSE[30232]: — Zap/2-1 answered Zap/1-1
Jun 15 13:06:08 VERBOSE[30232]: — Attempting native bridge of Zap/1-1
and Zap/2-1
Jun 15 13:06:31 VERBOSE[30232]: — Hungup ‘Zap/2-1’
Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
exited non-zero on ‘Zap/1-1’
Jun 15 13:06:31 VERBOSE[30232]: — Hungup ‘Zap/1-1’

I’ve contacted our PRI provider, however, they say that they do not see the call reach their system. To me, it would seem like the call is coming into our Asterisk system through our Zap interface on one channel, then attempting to leave the system through the Zap interface on another channel, and is failing to do so. Is there some sort of functionality I need to enable to facilitate this? (I’d rather wait till later to address the “why” this worked before and is no longer working)

On thing I’ll add, I can see where this DID work through what appears to be a SIP call — although this would be a different situation as it comes through via SIP then leaves via the Zap interface vs. the call coming through Zap and then also leaving via Zap:

Jun 3 09:59:09 VERBOSE[21021]: — Executing SetVar(“SIP/4851-a8e0”,
“oextenH51-a8e0”) in new stack Jun 3 09:59:09 VERBOSE[21021]: — Executing SetVar(“SIP/4851-a8e0”,
“extencidH51”) in new stack Jun 3 09:59:09 VERBOSE[21021]: — Executing SetCIDNum(“SIP/4851-a8e0”,
“4851”) in new stack Jun 3 09:59:09 VERBOSE[21021]: — Executing Goto(“SIP/4851-a8e0”,
“extensions|4832|1”) in new stack Jun 3 09:59:09 VERBOSE[21021]: — Goto (extensions,4832,1)
Jun 3 09:59:09 VERBOSE[21021]: — Executing Dial(“SIP/4851-a8e0”,
“zap/g1/1XXXXXX2222|20|tT”) in new stack Jun 3 09:59:09 VERBOSE[21021]: — Called g1/1XXXXXX2222
Jun 3 09:59:12 VERBOSE[21021]: — Zap/1-1 is ringing Jun 3 09:59:12 VERBOSE[21021]: — Zap/1-1 is ringing Jun 3 09:59:18 VERBOSE[21021]: — Zap/1-1 is ringing Jun 3 09:59:23 VERBOSE[21021]: — Zap/1-1 answered SIP/4851-a8e0
Jun 3 10:01:36 VERBOSE[21021]: — Hungup ‘Zap/1-1’
Jun 3 10:01:36 VERBOSE[21021]: == Spawn extension (extensions, 4832,
1) exited non-zero on ‘SIP/4851-a8e0’

I’m not sure that the above is relevant, but thought I’d throw it out there.

7 thoughts on - Issue Dialing Out

  • They are either incompetant or lying to you. Call appears to succeed (it is answered) and gets disconnected after 23s. You are not generating the message, so the calls gets back to you telco.

    Most likely someone is filtering on callerID (which is a good thing IMHO). Set the callerid to one of your numbers before sending it back to Zap and try again.

  • You’re right! Forgot to update this thread, but a tech from their side performed a trap on the line and attempted to recreate the issue. From their switch, they’re seeing the call go into our asterisk system, then leave the asterisk system (as it tries to dial the outside line when reaching the specific extensions 4832), then receiving a disconnect from our asterisk system almost immediately. So it would appear that asterisk attempts to forward the call as expected, then immediately disconnects for some unknown reason, which I guess is the specific issue I need to determine the cause of and resolve.

    I’m going to try what you’ve suggested and set the callerid to one of our numbers. Will let you know of the result.

    Thanks!

  • Setting the CID did not work, unfortunately 🙁

    Jun 15 14:50:31 VERBOSE[777]: — Accepting call from ‘XXXXXX6886’ to
    ‘XXXXXX3730’ on channel 0/1, span 1
    Jun 15 14:50:31 VERBOSE[31883]: — Executing Answer(“Zap/1-1”, “”) in new stack Jun 15 14:50:31 VERBOSE[31883]: — Executing Wait(“Zap/1-1”, “2”) in new stack Jun 15 14:50:33 VERBOSE[31883]: — Executing Goto(“Zap/1-1”,
    “pri-in-dids|XXXXXX3730|1”) in new stack Jun 15 14:50:33 VERBOSE[31883]: — Goto (pri-in-dids,XXXXXX3730,1)
    Jun 15 14:50:33 VERBOSE[31883]: — Executing Goto(“Zap/1-1”,
    “menu-v2|s|1”) in new stack Jun 15 14:50:33 VERBOSE[31883]: — Goto (menu-v2,s,1)
    Jun 15 14:50:33 VERBOSE[31883]: — Executing BackGround(“Zap/1-1”,
    “firstintro”) in new stack Jun 15 14:50:33 VERBOSE[31883]: — Playing ‘firstintro’ (language ‘en’)
    Jun 15 14:50:39 VERBOSE[31883]: == CDR updated on Zap/1-1
    Jun 15 14:50:39 VERBOSE[31883]: — Executing SetCIDNum(“Zap/1-1”,
    “XXXXXX3730”) in new stack Jun 15 14:50:39 VERBOSE[31883]: — Executing Dial(“Zap/1-1”,
    “zap/g1/1XXXXXX2222|20|tT”) in new stack Jun 15 14:50:39 VERBOSE[31883]: — Called g1/1XXXXXX2222
    Jun 15 14:50:42 VERBOSE[31883]: — Zap/2-1 answered Zap/1-1
    Jun 15 14:50:42 VERBOSE[31883]: — Attempting native bridge of Zap/1-1
    and Zap/2-1
    Jun 15 14:50:58 VERBOSE[777]: — Channel 0/1, span 1 got hangup Jun 15 14:50:58 VERBOSE[31883]: — Hungup ‘Zap/2-1’
    Jun 15 14:50:58 VERBOSE[31883]: == Spawn extension (menu-v2, 4832, 2)
    exited non-zero on ‘Zap/1-1’
    Jun 15 14:50:58 VERBOSE[31883]: — Hungup ‘Zap/1-1’

    I’m going to try another number that we have through them in hopes that it’ll complete and I’ll let you know if that works. Do you have any other suggestions on what you think they might be filtering by?

    In the trap given to me by the company, they show our system issuing a
    “disconnect” from our end, rather than their end dropping the call.

    Thanks for the assistance.

  • […]

    Do a “pri set debug” (or whatever it is called in 1.4 (zap?)) Zap/Zap bridging should work, it did on my PRIs and still does with DAHDI. Only thing I can think of is the TON/NPI might be a problem (but doubt it since SIP/Zap works).

  • Thanks so much for your suggestions.

    I’m running 1.0.x (yes, archaic, and in fact my actual task is migrating this system to asterisk11+Freepbx — very fun in and of itself without regards to this issue…but I digress), and so I needed to run “pri debug span “, which I’ve now done. I attempted the call again have pasted the debug output here:
    http://pastebin.com/cHHnMfh6

    I can’t thank you enough for your assistance, and I understand if you wouldn’t want to go through the debug output as it’s LONG — though I’m thinking most of the pertinent info as towards the end.

  • Dan, wanted to thank you again for your assistance. I got this worked out with our provider, it was actually an issue on their end that they’ve now corrected. Thanks again for your help!

  • You mentioned the telco receiving a DISCONNECT almost immediatly. Your debug is only up to a PROGRESS.

    I only have experience with euroisdn but callflow would be:
    ->SETUP
    < -CALLPROCEDING <-PROGRESS <-CONNECT ->CONNECT ACK
    ->DISCONNECT (eg from caller)
    < -RELEASE ->RELEASE COMPLETE

    But PROGRESS means the recipient is generating some audio (your unreachable message?). If this is an error message you would expect a RELASE from the telco after the recording if the caller doesn’t hangup first.

    You should study the difference of zap->zap and sip->zap callsetup.