cwernstedt Posted November 12, 2017 Report Share Posted November 12, 2017 We are running 59.0 (Debian64) . After about 7-8 days of problem free operation since the last re-boot, calls can no longer be successfully placed between pbx extensions or between extensions and mailboxes or conferences. (Calls out via trunks seem OK, but incoming trunk calls don't work.) Any ideas? I'll have to restart now, which will likely make it work again, but any suggestions for how to troubleshoot this if it comes back would be very helpful. Best, Christian Edit: Nope, not even rebooting helped. So I'm really stuck... Edit#2: Restarting did actually mitigate the worst of the issues. (Still not able to call conferences from the Web interface, but this may have been problematic before this incident.) Quote Link to comment Share on other sites More sharing options...
Support Posted November 13, 2017 Report Share Posted November 13, 2017 Hi, Could you get us the logs of those failed calls from the admin level for us to quickly see what is going on. Did anything else change on your trunk or system except upgrading to the version 59.0? Also, if you can test it out real quick, then can you try to upgrade to 59.1 and see if the issues are fixed. P.S.: Please take a full backup of your /usr/local/pbx folder before upgrading. And test this when you have the lowest or no business running. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted November 13, 2017 Report Share Posted November 13, 2017 If a restart does not help that would hint at problems outside the PBX, usually the firewall. What you can also check is how many sockets the PBX has open (lsof https://linux.die.net/man/8/lsof will help you if you are using Linux) and also generally ps to see if there is anything else unusual like memory. Although these resources should be reset after a restart, but you never know. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 13, 2017 Author Report Share Posted November 13, 2017 @Support The logs seem to be gone quite quickly and not much helpful info in them right after the problem happened either. I had SIP events logging set to a high number and these events quickly filled the 100 entry limit that was also set. I did receive some notification emails from the system about RTP timeout and "unconnected call" with regard to some WebRTC tests that I did, but currently this is all I have (unless more logs are stored somewhere in the pbx folder). So I think I'll have to wait until next time this happens (if it happens). However, I wonder if you could clarify what optimal log settings would be in order to capture these problems the next time. I need to increase logging detail and the number of entries saves, but I don't know what is reasonable, and I don't want to run into memory issues due to excessive logging. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 13, 2017 Author Report Share Posted November 13, 2017 @Vodia PBX Restart helped with the worst issues. Strangely enough, the problem remained that had to do with with WebRTC calls not working between an internal extension and a mailbox, and between the same extension and a conference . This problem has disappeared today with no intervention so currently everything back to normal after one restart and some waiting. Socket issue sounds maybe plausible. You mean that maybe the number of max sockets needs to increase on the OS level? (System is running on ubuntu, but I'm not an ubuntu expert.) Quote Link to comment Share on other sites More sharing options...
Support Posted November 13, 2017 Report Share Posted November 13, 2017 18 minutes ago, cwernstedt said: @Support The logs seem to be gone quite quickly and not much helpful info in them right after the problem happened either. I had SIP events logging set to a high number and these events quickly filled the 100 entry limit that was also set. I did receive some notification emails from the system about RTP timeout and "unconnected call" with regard to some WebRTC tests that I did, but currently this is all I have (unless more logs are stored somewhere in the pbx folder). So I think I'll have to wait until next time this happens (if it happens). However, I wonder if you could clarify what optimal log settings would be in order to capture these problems the next time. I need to increase logging detail and the number of entries saves, but I don't know what is reasonable, and I don't want to run into memory issues due to excessive logging. Hi, You wont run into any memory issues due to logs as they get overwritten once the limit is crossed. And these are logs you need to get us from the Admin level (as seen in the image as well). Also do get us the "lsof" commands output here. Please follow the link attached previously to learn more about lsof and how to fire the command from the terminal. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 13, 2017 Author Report Share Posted November 13, 2017 @Support OK. Thanks. I have changed the log settings. Re lsof , is this the output you're looking for?: lsof -i COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dhclient 934 root 6u IPv4 12027 0t0 UDP *:bootpc sshd 1085 root 3u IPv4 13694 0t0 TCP *:ssh (LISTEN) sshd 1085 root 4u IPv6 13696 0t0 TCP *:ssh (LISTEN) ntpd 1212 ntp 16u IPv6 15189 0t0 UDP *:ntp ntpd 1212 ntp 17u IPv4 15226 0t0 UDP *:ntp ntpd 1212 ntp 18u IPv4 15230 0t0 UDP localhost:ntp ntpd 1212 ntp 19u IPv4 15235 0t0 UDP 10.9.1.148:ntp ntpd 1212 ntp 20u IPv6 15237 0t0 UDP ip6-localhost:ntp ntpd 1212 ntp 21u IPv6 15239 0t0 UDP [fe80::d:abff:fe73:8699]:ntp pbxctrl 1219 root 2u IPv4 15832 0t0 UDP *:59542 pbxctrl 1219 root 3u IPv6 15833 0t0 UDP *:48916 pbxctrl 1219 root 4u IPv4 15837 0t0 TCP *:http (LISTEN) pbxctrl 1219 root 5u IPv6 15838 0t0 TCP *:http (LISTEN) pbxctrl 1219 root 6u IPv4 15839 0t0 TCP *:https (LISTEN) pbxctrl 1219 root 7u IPv6 15840 0t0 TCP *:https (LISTEN) pbxctrl 1219 root 8u IPv4 15841 0t0 TCP *:2345 (LISTEN) pbxctrl 1219 root 9u IPv6 15842 0t0 TCP *:2345 (LISTEN) pbxctrl 1219 root 10u IPv4 15843 0t0 TCP *:2346 (LISTEN) pbxctrl 1219 root 11u IPv6 15844 0t0 TCP *:2346 (LISTEN) pbxctrl 1219 root 12u IPv4 15845 0t0 UDP *:snmp pbxctrl 1219 root 13u IPv6 15846 0t0 UDP *:snmp pbxctrl 1219 root 14u IPv4 15847 0t0 UDP *:tftp pbxctrl 1219 root 15u IPv6 15848 0t0 UDP *:tftp pbxctrl 1219 root 16u IPv4 15857 0t0 UDP *:bootps pbxctrl 1219 root 17u IPv4 15849 0t0 UDP *:sip pbxctrl 1219 root 18u IPv6 15850 0t0 UDP *:sip pbxctrl 1219 root 19u IPv4 15851 0t0 TCP *:sip (LISTEN) pbxctrl 1219 root 20u IPv6 15852 0t0 TCP *:sip (LISTEN) pbxctrl 1219 root 21u IPv4 15853 0t0 TCP *:sip-tls (LISTEN) pbxctrl 1219 root 22u IPv6 15854 0t0 TCP *:sip-tls (LISTEN) pbxctrl 1219 root 23u IPv4 15855 0t0 UDP *:54794 pbxctrl 1219 root 24u IPv6 15856 0t0 UDP *:47046 pbxctrl 1219 root 25u IPv4 15858 0t0 UDP localhost:49654 pbxctrl 1219 root 26u IPv4 15859 0t0 UDP localhost:55429 pbxctrl 1219 root 28u IPv4 23134 0t0 UDP *:63386 pbxctrl 1219 root 29u IPv4 23135 0t0 UDP *:63387 pbxctrl 1219 root 30u IPv6 23136 0t0 UDP *:63386 pbxctrl 1219 root 31u IPv6 23137 0t0 UDP *:63387 pbxctrl 1219 root 32u IPv4 24862 0t0 UDP *:58668 pbxctrl 1219 root 33u IPv4 24863 0t0 UDP *:58669 pbxctrl 1219 root 34u IPv6 24864 0t0 UDP *:58668 pbxctrl 1219 root 35u IPv6 24865 0t0 UDP *:58669 pbxctrl 1219 root 46u IPv4 27410 0t0 TCP 10.0.1.148:https->10.0.2.41:62597 (ESTABLISHED) sshd 6670 root 3u IPv4 27763 0t0 TCP 10.0.1.148:ssh->10.0.2.41:63430 (ESTABLISHED) sshd 6708 ubuntu 3u IPv4 27763 0t0 TCP 10.0.1.148:ssh->10.0.2.41:63430 (ESTABLISHED) Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted November 15, 2017 Report Share Posted November 15, 2017 lsof looks ok. If we can narrow it down to the usage of WebRTC that would be a good hint. Then we can try to have e.g. a hundred WebRTC calls in the lab and see if anything gets out of control. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 15, 2017 Author Report Share Posted November 15, 2017 It could have been triggered by WebRTC usage, but the effects weren't limited to such. Extremely little usage at this point. Just me and a couple of other users, making/receiving calls a few times per day. Rarely simultaneously. I was doing various fiddling around with different SIP clients and maybe WebRTC right before things stopped working. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.