Jump to content

cwernstedt

Members
  • Posts

    103
  • Joined

  • Last visited

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

     

     

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

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

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

  6. 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 . skype-connect-requirements-guide.pdf

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

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

     

     

  10. :) Okay, seems like we cannot blame the ITSP this time. We are currently investigating if there is a difference between the Windows and Linux abstraction for locking. Seems that Windows works better, and we need to have the same behavior in Linux as well. Let us know if you want to be the ginuea pig and try it out on the MAC.

     

    I wouldn't mind trying out something that might fix this.

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

×
×
  • Create New...