Elastix: Outbound calling issue
-
We are looking at a Elastix system that has had out bound calling issues twice this week. We have 'resolved' the issue by force restarting the PBX system. But this is not a solution mid day.
IO wait times have been below 1, with a 1.4 average as best as I see.
07:30:02 AM CPU %user %nice %system %iowait %steal %idle 07:40:01 AM all 0.03 0.00 0.09 0.23 0.00 99.65 07:50:01 AM all 0.03 0.00 0.10 0.41 0.00 99.46 08:00:01 AM all 0.03 0.00 0.09 0.27 0.00 99.60 08:10:01 AM all 0.03 0.00 0.09 0.33 0.00 99.54 08:20:01 AM all 0.03 0.00 0.10 0.29 0.00 99.58 08:30:01 AM all 0.06 0.00 0.09 0.26 0.00 99.60 08:40:01 AM all 0.03 0.00 0.09 0.30 0.00 99.58 08:50:01 AM all 0.03 0.00 0.10 0.21 0.00 99.66 09:00:01 AM all 0.03 0.00 0.09 0.30 0.00 99.57 09:10:01 AM all 0.04 0.00 0.09 0.31 0.00 99.56 09:20:01 AM all 0.03 0.00 0.11 0.28 0.00 99.58 09:30:01 AM all 0.13 0.00 0.17 0.75 0.00 98.95 09:40:01 AM all 0.88 0.00 0.15 0.40 0.00 98.57 09:50:01 AM all 1.40 0.00 0.19 0.64 0.00 97.78 10:00:01 AM all 3.17 0.00 0.44 1.41 0.00 94.98 10:10:01 AM all 3.39 0.00 0.69 0.87 0.00 95.06 10:20:01 AM all 2.98 0.00 0.60 0.74 0.00 95.68 10:30:01 AM all 2.77 0.00 0.32 0.56 0.00 96.35 Average: all 0.27 0.00 0.13 1.03 0.00 98.57free -m total used free shared buffers cached Mem: 1001 615 386 0 7 68 -/+ buffers/cache: 539 462 Swap: 2015 0 2015 -
Current GUI panel report
It does not seem that the system is using any of the swap memory...
-
What else should I be looking for to try to isolate this issue? There doesn't seem to be a problem with the SIP provider, or the PBX itself. But I could easily miss something.
-
We've looked at SAR reports previously, CPU and memory are definitely not the issue.
-
Next step is scouring the system logs around the time of the loss of connectivity.
-
One thing that may need to be looked at is the Host. This PBX is running on a VMware host. Could the Host some how be causing the issue and not the PBX itself?
-
@g.jacobse said:
One thing that may need to be looked at is the Host. This PBX is running on a VMware host. Could the Host some how be causing the issue and not the PBX itself?
Not realistically.
-
Outbound calling via SIP or PRI?
-
@scottalanmiller said:
@g.jacobse said:
One thing that may need to be looked at is the Host. This PBX is running on a VMware host. Could the Host some how be causing the issue and not the PBX itself?
Not realistically.
Why not? Let's assume he only has one NIC in the VM host - if it gets saturated by another VM. So before you can dismiss it, don't you have to ask about the host config?
-
@coliver said:
Outbound calling via SIP or PRI?
SIP via Vitality.
The Vitality logs have been investigated.
-
@Dashrender said:
Why not? Let's assume he only has one NIC in the VM host - if it gets saturated by another VM. So before you can dismiss it, don't you have to ask about the host config?
Because that would not impact solely outbound call setup. If that were happening we would lose inbound calling, existing calls, remote access, etc. Call setup uses trivial network resources, if we were approaching that level everything in the office would be broken AND rebooting could not fix it.
-
@scottalanmiller said:
@Dashrender said:
Why not? Let's assume he only has one NIC in the VM host - if it gets saturated by another VM. So before you can dismiss it, don't you have to ask about the host config?
Because that would not impact solely outbound call setup. If that were happening we would lose inbound calling, existing calls, remote access, etc. Call setup uses trivial network resources, if we were approaching that level everything in the office would be broken AND rebooting could not fix it.
Good point!
-
Memory seems to be creeping up again.
06:20:01 PM CPU %user %nice %system %iowait %steal %idle 06:30:01 PM all 1.51 0.00 0.19 0.39 0.00 97.91 06:40:01 PM all 1.44 0.00 0.18 0.75 0.00 97.62 06:50:01 PM all 1.42 0.00 0.19 0.65 0.00 97.74 07:00:01 PM all 1.39 0.00 0.18 1.00 0.00 97.43 07:10:01 PM all 1.55 0.00 0.19 0.43 0.00 97.84 07:20:01 PM all 1.42 0.00 0.19 0.71 0.00 97.68 07:30:01 PM all 1.46 0.00 0.18 0.70 0.00 97.66 07:40:01 PM all 1.42 0.00 0.18 0.51 0.00 97.89 07:50:01 PM all 1.44 0.00 0.18 0.62 0.00 97.75 08:00:01 PM all 1.43 0.00 0.17 0.59 0.00 97.82 08:10:01 PM all 1.42 0.00 0.18 0.61 0.00 97.79 Average: all 0.91 0.00 0.20 0.84 0.00 98.05$ free -m total used free shared buffers cached Mem: 1001 607 394 0 63 90 -/+ buffers/cache: 453 548 Swap: 2015 0 2015$ /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using pbx.[xxx] .com for ServerName [ OK ]$ free -m total used free shared buffers cached Mem: 1001 336 665 0 63 90 -/+ buffers/cache: 182 819 Swap: 2015 0 2015 [root@pbx ~]#The command /etc/init.d/httpd restart was suggested by @scottalanmiller .
-
The memory drop at about 14:00 was the first time I ran it,And again just at 20:20
-
Any new issues since the Apache restart?
-
@scottalanmiller said:
Any new issues since the Apache restart?
They are no longer in the office today. I am not aware of any new issues or complaints. There is other host / server maintenance needed at this site this weekend, so I expect at some point between now and late Sunday both servers will be restarted.
I will continue to monitor the system, but otherwise will not restart Apache again.
-
Elastix 2.4 or 2.5 by the way? Just curious.
-
-
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.
