Trunks misbehaving; vitelity suggests freepbx/asterisk issue

Beta Program Issues
1

The server:
FreePBX 2.3.0beta1
Asterisk Ver. 1.2.36078

The setup:
Inbound DID with IVR from IPKall
Inbound DID with IVR from Vitelity
Outbound Dialing with 2 Viatalk Trunks; one has caller ID blocked, the other does not
Outbound Dialing with 1 Vitelity Trunk

Connected SIP Devices:
X-Lite 3.0 Softphone
PAP2-NA

All incoming calls to the IVR work just fine when they originate from a POTS line or a cell phone. When the call comes in to any of the numbers with an IVR destination from OUTSIDE my server (i.e.: POTS, or Cell Phone), it always works just fine. Give it a go on the IPKall number if you wish:
1 (360) 488-0476

I’ve been going back and forth with Vitelity’s support, we tried modifying my Trunk so it no longer uses the SIP register string, and they point all the calls to my static IP directly. This did not change the behaviour.

But…

On the PAP2-NA:
Outbound calls to all US telephone numbers work fine on all the trunks, as long as the outbound call isn’t going to a DID on my server that is configured to have an IVR. So if I call a number that is going to ring a SIP extension, it works fine. If I call a number with an IVR associated with it, the IVR never starts. It doesn’t matter what trunk I use to make the outbound call to reach my IVR, or which carrier’s DID I’m using to get to the IVR.

Here’s the interesting twist. In the Vitelity control panel, if the Vitelity DID pointing to an IVR fails, the failover number I set is an IPKall number pointing to the same IVR. When I use the Vitelity outbound trunk to call this DID, I get silence. If I remove the failover number, the CLI output is a little more interesting:

[code:1] – Called VitelityOutbound/18663153263
– Got SIP response 486 “Busy here” back from 64.2.142.17
– SIP/VitelityOutbound-09c79d40 is busy
== Everyone is busy/congested at this time (1:1/0/0)
– Executing Goto(“SIP/3604880489-b7b1b850”, “s-BUSY|1”) in new stack
– Goto (macro-dialout-trunk,s-BUSY,1)
– Executing NoOp(“SIP/3604880489-b7b1b850”, “Dial failed due to trunk reporting BUSY - giving up”) in new stack
– Executing Busy(“SIP/3604880489-b7b1b850”, “20”) in new stack
== Spawn extension (macro-dialout-trunk, s-BUSY, 2) exited non-zero on ‘SIP/3604880489-b7b1b850’ in macro ‘dialout-trunk’
== Spawn extension (macro-dialout-trunk, s-BUSY, 2) exited non-zero on ‘SIP/3604880489-b7b1b850’[/code:1]

On the X-Lite 3.0 Softphone
Outbound calls to all US telephone numbers work fine on all trunks with the following exceptions:

With the Viatalk Trunk with the Caller ID Blocked:
Calls successfully reaches IPKall, I know this because IPKall doesn’t accept calls from private numbers, and their system prompts me to enter a phone number to identify myself. The call should connect once I do that, but the IVR greeting never starts. (I never hear it, and it doesn’t show up as being played in the CLI.) There is dead air, and eventually some sort of time-out kicks in and the call ends. I see the ‘SPAWN’ lines pop up in the CLI as the call disconnects.
If I try using this Viatalk trunk to dial a Vitelity DID that also points to the IVR, I get a ‘CONGESTION’ error email from Vitelity, notifying me of the failed call. In the Asterisk CLI I see the outbound call has been made, but the recording for the IVR never starts. Specifically, Vitelity says “This error usually means your server or device does not recognize the number being dialed. If using asterisk, make sure you have the correct inbound context specified on your inbound trunk and that you have correctly added an inbound route/extension logic for this DID.” I see the call show up as 0 seconds in my CDR with Vitelity, and as “NO ANSWER” and a call duration reflecting how long I listened to dead air. Interestingly enough, unlike the softphone, if I remove the failover number in the Vitelity control panel, the CLI output doesn’t show the snippet I added earlier, the call does not terminate - it keeps going, with dead air.

With the Viatalk Trunk with the Caller ID Enabled:
Dead air. I see the call being made, but I may as well look for the automagically generated ‘call failed error email’ from Vitelity (pretty neat feature!).

With Vitelity:
Dead air when I call the IPKall number. It successfully plays the IVR when I call the Vitelity DIDs!

{ripping my hair out in frustration} :shock:
A quick glance at the Asterisk Logfile would corroborate my issues:
http://pastebin.com/f25e206cc

Given all this back and forth with the carrier, and based on what I’m seeing in the CLI, my speculation is the problem does not lay with the carrier, but moreso with my setup. Any suggestions?

I see a new 2.3.0beta2.0 Core module is up, but it doesn’t let me upgrade. I’m hoping this issue will perhaps eliminate itself when upgrade instructions come out. Is there a possibility I need to upgrade my Asterisk to a later version?

2

It does not appear to connect to anything or is dead air.

I might try an uncomplicated approach. Take all trunks and routes out, then add one provider at a time starting with Vitelity and ending with IPKall.

You might have an “aha” moment at the point when it fails if you test each one as you add them.

Also, what version of Asterisk? For me, I stick with released versions so I can concentrate on FreePBX when in Beta mode.

3

I did not have time to read though your post, so maybe I missed something. But as a general note, when a provider tells you that is is an issue with ‘FreepBX’ - it’s typically a ‘cop out’ in their willingness to help you, in most cases. (or they are telling you that you configured it wrong in FreePBX which very well may be the case).

For trunks, FreePBX leaves you at the ‘mercy’ of doing it right, with very little help. (Hopefully, that will change in the future). In addition, that part of the code has not changed in a LONG LONG time - and it works… (hopefully that is another thing that will change in the future - the code not changing, not the working part:))

4

Ha! No worries my friend, I just thought a detailed post would help unveil a potentially interesting bug to be squished. I’m looking through everything and it looks like maybe upgrading Asterisk would do the trick.

What are your thoughts of upgrading to the new freepbx2.3.0beta2.0 and running Asterisk 1.4? (Stable?)

Poking around for a good set of instructions on upgrading Asterisk, any pointers off the top of your head or should I just utilize Google?

Keep up the excellent work!

5

I wouldn’t upgrade a production system to Asterisk 1.4 unless there is something in 1.4 that you explicitly need. As far as FreePBX 2.3.0beta2 - we are happy to have the beta testing, but give that it is barely out the door (the tarballs have not even been through the final verification and distribution) so … make you own choice.

6

Hi Philippe,

don’t forget that Asterisk 1.2 officially ‘End of life’ and will no longer be maintained as of 1st August 2007.
(Announced on ‘Asterisk-users’ list 29th May 2007).

Users will have to switch to 1.4 if they want anything more than security fixes.

7

[quote=“rjenkinsgb”]Hi Philippe,

don’t forget that Asterisk 1.2 officially ‘End of life’ and will no longer be maintained as of 1st August 2007.
(Announced on ‘Asterisk-users’ list 29th May 2007).

Users will have to switch to 1.4 if they want anything more than security fixes.[/quote]
Take a look at the history of bug fixes from Asterisk. What I find is that more often then not my only desire is to get the security patch since often there are more bugs introduced and none fixed that affect me. On many occasions I have specifically pulled just the security patch and not the release.

My point here is that you may actually find 1.2 become ‘more stable’ as a result of limiting fixes to security patches. You will find Asterisk 1.2 running strong for a long time to come.

This does not mean I have anything against Asterisk 1.4 and it was to help Digium drive stability into their release that we pushed 2.3 out when we did. That does not mean I will run any production systems on 1.4 yet - there are still too many issues that I see at this early stage.

8

So I isolated the problem after testing with X-Lite and Idefisk. My PAP2 is causing the busy signal when the call goes out over a trunk and rings a DID that is on the server. (I.e: if my PAP2 extension calls out over Vitelity to reach an 800 number, which should play an IVR.)

Extension to extension dialing is fine. What a bummer… anybody have input?

9

Ok - if anyone else has this problem - use Miscellaneous Applications to route your internal calls to the right destination. Very easy to set up within freepbx, saves you money, and it’s more efficient.

It got rid of the busy signal issue I was having when calling DIDs on my own asterisk box :slight_smile:

10

Would you mind elaborating on your fix?

11

I had a similar issue today (randomly) on a random number of trunks.
I found the issue.

The trunks with “random” chanunavail or busy responses, all had ENUM caller ID lookups… as soon as I removed it, everything started working as expected.

(bad me… don’t use enum again any time soon… bad me)

12

I gave up on ENUM a long time ago, when a PBX is acting up that is the one of things on my list of “TO REMOVE” (In one day I had seven companies calling because they coluld not call cell phones…all where enum lookup failure releated…the cell phones where hitting a black hole I reckon.