Elastix: Outbound calling issue
-
I'm not sure you ever actually specified what you mean by outbound calling issues. Do you get a busy signal, all circuits busy now, some other error, etc.?
Check the trunk settings, and make sure you have disallow=all in there and allow=ulaw under it (need to check Vitelity documentation on this). If I remember right, Vitelity requires separate trunk setups (at least in the Elastix sense of the word trunk) for inbound and outbound calling. Hopefully you do not have allow=ulaw&g729 because I have seen instances where Elastix (at least in 2.4) will actually try to use g729 outbound, and you get one-way audio.
You could do a tcpdump on the Elastix box, make some calls when this situation happens, download the tcpdump to your machine, and open with Wireshark to see a visual flow of traffic. That may give you some insight.
-
@NetworkNerd said:
I'm not sure you ever actually specified what you mean by outbound calling issues. Do you get a busy signal, all circuits busy now, some other error, etc.?
It was stated earlier that the trunk works inbound and outbound and then just suddenly stops making outbound calls. Inbound continue working.
-
@JaredBusch said:
@NetworkNerd said:
I'm not sure you ever actually specified what you mean by outbound calling issues. Do you get a busy signal, all circuits busy now, some other error, etc.?
It was stated earlier that the trunk works inbound and outbound and then just suddenly stops making outbound calls. Inbound continue working.
yes, the system operates normally 90% of the time,.. then suddenly twice in a week the customer was unable to make outbound calls. They didn't say the exact error, but my guess is that they get all circuits are busy or a fast busy.
I have not checked it yet, I was informed that with some updates from MS,.. all the servers were restarted yesterday.
-
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
-
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
-
current GUI
-
Sar:
sar Linux 2.6.18-371.1.2.el5 (pbx.XXX.com) 08/16/2015 12:00:01 AM CPU %user %nice %system %iowait %steal %idle 12:10:01 AM all 0.05 0.00 0.09 1.81 0.00 98.06 12:20:01 AM all 0.04 0.00 0.10 1.12 0.00 98.74 12:30:01 AM all 0.07 0.00 0.09 0.95 0.00 98.89 12:40:01 AM all 0.05 0.00 0.09 1.17 0.00 98.69 12:50:01 AM all 0.04 0.00 0.10 1.64 0.00 98.22 01:00:01 AM all 0.05 0.00 0.09 1.81 0.00 98.05 01:10:01 AM all 0.04 0.00 0.09 1.53 0.00 98.34 01:20:01 AM all 0.04 0.00 0.10 1.05 0.00 98.81 01:30:01 AM all 0.07 0.00 0.10 1.37 0.00 98.46 01:40:01 AM all 0.04 0.00 0.09 1.57 0.00 98.30 01:50:01 AM all 0.04 0.00 0.10 1.35 0.00 98.51 02:00:01 AM all 0.04 0.00 0.09 0.96 0.00 98.91 02:10:01 AM all 0.04 0.00 0.09 1.65 0.00 98.21 02:20:01 AM all 0.04 0.00 0.10 1.35 0.00 98.51 02:30:01 AM all 0.07 0.00 0.09 1.55 0.00 98.29 02:40:01 AM all 0.04 0.00 0.08 1.18 0.00 98.70 02:50:01 AM all 0.04 0.00 0.10 1.18 0.00 98.68 03:00:01 AM all 0.04 0.00 0.08 1.17 0.00 98.71 03:10:01 AM all 0.05 0.00 0.09 1.91 0.00 97.95 03:20:01 AM all 0.04 0.00 0.11 0.91 0.00 98.94 03:30:01 AM all 0.07 0.00 0.10 1.16 0.00 98.67 03:40:01 AM all 0.04 0.00 0.09 1.10 0.00 98.77 03:40:01 AM CPU %user %nice %system %iowait %steal %idle 03:50:01 AM all 0.04 0.00 0.10 1.33 0.00 98.54 04:00:01 AM all 0.04 0.00 0.09 1.23 0.00 98.64 04:10:01 AM all 0.28 0.00 0.18 1.78 0.00 97.76 04:20:01 AM all 0.04 0.00 0.10 1.67 0.00 98.18 04:30:01 AM all 0.07 0.00 0.10 1.33 0.00 98.50 04:40:01 AM all 0.04 0.00 0.09 1.31 0.00 98.57 04:50:01 AM all 0.04 0.00 0.10 1.38 0.00 98.48 05:00:01 AM all 0.04 0.00 0.09 1.34 0.00 98.53 05:10:01 AM all 0.04 0.00 0.09 1.62 0.00 98.24 05:20:01 AM all 0.04 0.00 0.11 1.10 0.00 98.75 05:30:01 AM all 0.06 0.00 0.10 1.22 0.00 98.62 05:40:01 AM all 0.04 0.00 0.09 1.43 0.00 98.44 05:50:01 AM all 0.04 0.00 0.10 1.68 0.00 98.17 06:00:01 AM all 0.04 0.00 0.09 1.34 0.00 98.53 06:10:01 AM all 0.05 0.00 0.09 1.11 0.00 98.75 06:20:01 AM all 0.04 0.00 0.10 0.72 0.00 99.14 06:30:01 AM all 0.07 0.00 0.10 1.04 0.00 98.79 06:40:01 AM all 0.04 0.00 0.09 1.58 0.00 98.30 06:50:01 AM all 0.04 0.00 0.10 1.28 0.00 98.58 07:00:01 AM all 0.03 0.00 0.07 0.75 0.00 99.14 07:10:01 AM all 0.04 0.00 0.07 0.38 0.00 99.51 07:20:01 AM all 0.04 0.00 0.08 0.29 0.00 99.60 07:20:01 AM CPU %user %nice %system %iowait %steal %idle 07:30:01 AM all 0.06 0.00 0.09 0.30 0.00 99.56 07:40:01 AM all 0.04 0.00 0.08 0.27 0.00 99.61 07:50:01 AM all 0.04 0.00 0.09 0.27 0.00 99.61 08:00:01 AM all 0.03 0.00 0.07 0.25 0.00 99.64 08:10:01 AM all 0.04 0.00 0.07 0.34 0.00 99.55 08:20:01 AM all 0.04 0.00 0.08 0.42 0.00 99.46 08:30:01 AM all 0.06 0.00 0.08 0.32 0.00 99.55 08:40:01 AM all 0.03 0.00 0.07 0.36 0.00 99.54 08:50:01 AM all 0.04 0.00 0.08 0.29 0.00 99.59 09:00:01 AM all 0.03 0.00 0.07 0.31 0.00 99.58 09:10:01 AM all 0.04 0.00 0.08 0.39 0.00 99.50 09:20:01 AM all 0.04 0.00 0.09 0.34 0.00 99.53 09:30:01 AM all 0.06 0.00 0.08 0.28 0.00 99.58 09:40:01 AM all 0.03 0.00 0.07 0.30 0.00 99.60 09:50:01 AM all 0.04 0.00 0.08 0.33 0.00 99.55 10:00:01 AM all 0.04 0.00 0.07 0.37 0.00 99.52 10:10:01 AM all 0.04 0.00 0.08 0.37 0.00 99.52 10:20:01 AM all 0.03 0.00 0.08 0.31 0.00 99.58 10:30:01 AM all 0.06 0.00 0.08 0.65 0.00 99.22 10:40:01 AM all 0.03 0.00 0.07 0.37 0.00 99.53 10:50:01 AM all 0.04 0.00 0.08 0.35 0.00 99.53 11:00:01 AM all 0.04 0.00 0.07 0.31 0.00 99.58 11:00:01 AM CPU %user %nice %system %iowait %steal %idle 11:10:01 AM all 0.03 0.00 0.08 0.34 0.00 99.55 11:20:01 AM all 0.04 0.00 0.09 0.29 0.00 99.58 11:30:01 AM all 0.06 0.00 0.08 0.37 0.00 99.48 11:40:01 AM all 0.04 0.00 0.08 0.29 0.00 99.60 11:50:01 AM all 0.04 0.00 0.09 0.35 0.00 99.53 12:00:01 PM all 0.04 0.00 0.08 0.25 0.00 99.64 12:10:01 PM all 0.04 0.00 0.08 0.39 0.00 99.50 12:20:01 PM all 0.03 0.00 0.08 0.30 0.00 99.58 Average: all 0.05 0.00 0.09 0.90 0.00 98.97 -
@g.jacobse said:
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
What is the connection between a DC (Windows VM) needing an update have with a PBX? There is some connection here that we aren't being told.
-
Based on your screenshots, there was no reboot. Who told you that they rebooted?
-
@scottalanmiller said:
@g.jacobse said:
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
What is the connection between a DC (Windows VM) needing an update have with a PBX? There is some connection here that we aren't being told.
No - DC and the PBX Host are different machines
-
@g.jacobse said:
No - DC and the PBX Host are different machines
I know. So why does anything with the DC mean anything with the PBX?
-
@scottalanmiller said:
Based on your screenshots, there was no reboot. Who told you that they rebooted?
Reboot would have been before 14:00 EDT yesterday
-
@g.jacobse said:
Reboot would have been before 14:00 EDT yesterday
Yes, more than two days ago is the last reboot. It says right on the screen that you showed.
-
uptime 12:28:49 up 2 days, 22:19, 1 user, load average: 0.00, 0.00, 0.00I may have been incorrectly informed as such then. I will have to validate that statement.
-
I think it is safe to stop looking at the FreePBX capacity screen and the SAR reports. There is no reason to believe that there is a capacity issue and the FreePBX screen shows wrong information and should never be used for this type of diagnoses anyway. SAR shows no issues with capacity even when there is a problem. Continuing to look at them is just distracting from diagnosis at this point.
There isn't much to work with, unless the logs show something, the best option is to look at the system at a time during which it has failed.
-
@g.jacobse said:
uptime 12:28:49 up 2 days, 22:19, 1 user, load average: 0.00, 0.00, 0.00I may have been incorrectly informed as such then. I will have to validate that statement.
Well if someone was telling you that it was rebooted because the DC rebooted, there is bad information guaranteed since "because" makes no sense in that case.
-
I have to admit that some assumptions were made on my part. These assumptions are incorrect. the VM host may have been rebooted but that doesn't seem (as shown) that it affected the VM.
This is most likely a case of sitting to close to the screen and not seeing the larger picture of how VMs work.
-
We've been through the /var/log/messages log and there is nothing in there to say that anything was amiss. This doesn't mean that nothing was logged but it does suggest that issues are in Asterisk or the trunk and not within the OS.
-
You should scour the Asterisk log from the time period when the outbound calls failed to see if there is something anomalous that happened around that time.
-
What is the call volume? I've read reports of Vitelity doing some strange things when there is a lot of calling. This seems to be linked to the trunk somehow and the best way to diagnose that is to dig into the Asterisk logs and see if there are any rejection messages related to the trunk.
