Elastix: Outbound calling 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.
-
@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
