Jump to content

cwernstedt

Members
  • Posts

    103
  • Joined

  • Last visited

Everything posted by cwernstedt

  1. Hi, My customer switched from an old pbxnsip installation to a new Vodia PBX (latest version) . On the old installation, SIP clients running on phones/laptops connecting with VPN (IPSEC or OpenVPN/SSL) to the PBX's location had no issues with placing calls through the PBX. On the new installation, on the other hand, there's one way audio (IPSEC) or no audio (OpenVPN) . I suspect it has to do with NAT (rather than with VPN as such) because SIP clients on various LANs that are interconnected via IPSEC tunnels have no issues. Any suggestions? Note again: Things worked straight out of the box with the old pbxnsip, but it doesn't work on the new Vodia installation. Cheers, Christian
  2. 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.
  3. @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)
  4. @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.)
  5. @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.
  6. 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.)
  7. Yes, my suspicion is that Skype has quietly dropped support for the needed ports and protocols.... For our Swiss provider things seem to "just work"...(Though I haven't been able to verify that SRTP is actually happening.)
  8. OK. Tried that. But no luck. sip:sip.skype.com;transport=tls results in timeout errors. What confuses me is that in the SRV records (which I must admit that I don't fully understand) I see references to both TLS and SIPS... There is also a document from Skype here which details what to do to get TLS and sRTP .
  9. Hm... The VOIP provider template for Skype sets the proxy to sip:sip.skype.com:5060 suggesting that it doesn't attempt TLS (right)? Setting the proxy simply to sip.skype.com doesn't work . SRV records look like this, suggesting that sips and TLS should be possible, but still doesn't work.. A 1.sip.skype.com 63.209.144.201 00:19 A 2.sip.skype.com 204.9.161.164 00:19 A sip.skype.com 63.209.144.201 00:19 AAAA 1.sip.skype.com 11:28:15 AAAA 2.sip.skype.com 11:28:15 AAAA sip.skype.com 11:28:15 NAPTR sip.skype.com 11:28:15 SRV _sip._tcp.sip.skype.com 11:28:15 SRV _sip._tls.sip.skype.com 11:28:15 SRV _sip._udp.sip.skype.com 0 0 1.sip.skype.com 5060 1 0 2.sip.skype.com 5060 00:19 SRV _sips._tcp.sip.skype.com 1 0 2.sip.skype.com 5061 0 0 1.sip.skype.com 5061
  10. So it can't be enforced on the PBX itself? Incoming calls may not ultimately terminate on a phone but in a voice mail box or conference room... With a cloud based PBX communicating across the globe to SIP providers, it seems crazy to not even know if one has RTP encryption or not..
  11. Hi, I haven't yet thought about how to secure phones and other user agents. Right now I'm primarily trying to secure traffic to and from SIP trunk providers.
  12. Does anyone know if TLS with Skype should "just work" if using the standard template, or if any particular settings are needed? I get all sorts of errors if I try to force port 5061 or put sips: in the outbound proxy address. Best, Christian
  13. Hi, I have some SIP trunks to SIP/Voip providers: Skype and a Swiss provider (Winet.ch) . I'm trying figure out how to achieve only TLS encrypted traffic on these connections. I find it tricky as I can't force TLS (neither service responds to port 5061 ), but DNS SRV records seem to be used. Is there a "best practice" way to make sure that only TLS is used? Cheers, Christian
  14. Is this supposed to work, or is it better to wait to test this until later? (The UI doesn't seem to respond in Chrome when attempting to dial.) Cheers, Christian
  15. Actually, I now got sound after upgrading Chrome to 59.0.3071.86 . Yes, I was using https, but with the server's self signed certificate Will continue to test later. Thanks!
  16. Hi, I'm making some initial tests, trying to make and receive calls via the web interface. I'm immediately running into the problem that I hear no sound whatsoever. (Answered yes to security prompts etc.) Any advice? Cheers, Christian Client setup: - Mac OS X 10.11.6 - Google Chrome 58.0.3029.110
  17. Phones can no longer register to the pbx itself, so it's not a provider issue. Restarting the pbx helps immediately.
  18. I just had this problem on a second Mac system, but did not have a chance to capture any info before someone restarted the pbx. It seems to happen extremely rarely (months in between), but it never happened on my Windows based systems.
  19. Restarting the phone doesn't help, but restarting the PBX (the entire server machine) helps - see my initial message about the subject. I don't know how to only restart the PBX service on a Mac without restarting the machine.
  20. I have a number entered as black listed in the phone book, but absolutely nothing changes in what happens when calls are received from this number. The call is routed through. The same thing happens if the number is black listed in the domain wide phone book. The black list function doesn't seem to work.
  21. A DNS lookup should not be necessary in order to reach the phone. (Or does the pbx generally try to do a DNS lookup when a phone registers?) The phone is on the same network, and it is possible to ping the phone from the PBX. /C
×
×
  • Create New...