Jump to content
Vodia PBX forum
cwernstedt

Suddenly calls "intra pbx" not working (no audio)

Recommended Posts

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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@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.)

Share this post


Link to post
Share on other sites
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.

1.png

Share this post


Link to post
Share on other sites

@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)

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×