[Solved] Dial out issue

Asterisk Asterisk Support
1

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”, “oexten=4851-a8e0”) in new stack
Jun 3 09:59:09 VERBOSE[21021]: – Executing SetVar(“SIP/4851-a8e0”, “extencid=4851”) 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.

2

[Somewhat of an] Update:

Just got off the line with our PRI provider. The tech 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.

From my limited understanding, it would seem there might be an issue with this:
“Attempting native bridge of Zap/1-1 and Zap/2-1”

I’m scouring the web now for hints on why this might be failing.

Thanks everyone for taking the time to look at this thread :smile:

3

Your first call is successful, although it is possible that answer supervision was locally fake.

The voice announcement is coming from the central office on the outgoing side, so the call definitely reached them.

The second call is on an FXS interface, or on an FXO one that definitely has answer supervision.

Asterisk thinks the call was up for 19 seconds before it dropped.

Native bridging means that the audio is being relayed by the voice card, rather than through the CPU. Specifying a Dial option that requires DTMF tobe decoded will probably disable it.

4

[quote=“david55”]Your first call is successful, although it is possible that answer supervision was locally fake.

The voice announcement is coming from the central office on the outgoing side, so the call definitely reached them.

The second call is on an FXS interface, or on an FXO one that definitely has answer supervision.

Asterisk thinks the call was up for 19 seconds before it dropped.

Native bridging means that the audio is being relayed by the voice card, rather than through the CPU. Specifying a Dial option that requires DTMF tobe decoded will probably disable it.[/quote]

Thanks for clarifying what “native bridging” actually means! I had an idea, but turns out I wasn’t close, heh.

From what you can see from the logs I posted, do you have an idea of where the issue may lie, or perhaps are you able to point me in the right direction to further troubleshoot? Do you think disabling the native bridging might have an affect on this? I only mentioned native bridging because I’m naive and still pretty much a newb to this whole thing, though I’ve done LOT’S of reading over the past month or so.

On the mailing list, someone suggested I might be getting filtered due to the caller-id, and that setting it to one of their numbers may work. I tried it, but this did not work, unfortunately :frowning:

5

Thanks again david for your suggestions. This ended up being an issue with our provider that we’ve now worked out. The issue is now resolved.