Jump to content
Vodia PBX forum

cwernstedt

Members
  • Content Count

    62
  • Joined

  • Last visited

Community Reputation

0 Neutral

About cwernstedt

  • Rank
    Advanced Member
  1. OK. I think to move things forward a bit faster than trial and error, I should pay for some consulting from someone skilled with setting up auto-provisioning with Snom and Vodia. (Should be fairly standard scenario.) To make this happen, do you recommend that I purchase some premium support tickets?
  2. I don't PnP the phone yet. It's not in the same LAN as the PBX so not sure how to do it properly at this point, but I'd like to solve this when the installation grows. Is PnP necessary for as-feature-event subscription?
  3. Is DND state syncing between snom D785 and Vodia 60.0.2 supposed to work? using_server_managed_dnd1=on ...but state changes on the PBX don't show up on the phone.
  4. @Support I sent the numbers in a private message to you here on the forum.
  5. I couldn’t find any SIP messages going out to the trunk when the particular cell phone number is used. SIP messages were sent when the working number was used.
  6. I'm trying out the 60.0.1 release. Having some trouble: - Cell pone redirect for an extension (114) to a certain number (+6421NNNNNN) stopped working. - Calling +6421NNNNNN from the 114 extension works. - Cell pone redirect for the extension works when set to a different but similar number (+6427NNNNNNN) . Note that the number that works has more digits than the number that doesn't work. It is not likely that the issue is with the outgoing trunk, because the log doesn't indicate any INVITE messages sent through the trunk when 114 is called and cell phone is set to +6421NNNNNN , and the trunk operator (Twilio) doesn't log any attempts or errors. Dial Plan used by 114: 101;Twilio (CH Office);;00*;"sip:+\1@\r;user=phone";;false 103;Twilio (CH Office);;0*;"sip:+41\1@\r;user=phone";;false104;Twilio (CH Office);;5500*;"sip:+\1@\r;user=phone";;false105;Twilio (CH Office);;550*;"sip:+41\1@\r;user=phone";;false106;Twilio (CH Office);;+*;"sip:+\1@\r;user=phone";;false The setup works in v59.0
  7. cwernstedt

    Let's Encrypt SSL Certificate support?

    +1
  8. cwernstedt

    caller id passthrough

    One of our operators, Twilio, says it's OK with our PBX "spoofing" the CID when calling out on their trunks for as long as the CID belongs to someone calling into their system. This would enable us to forward the actual originating CID to our cell phones. Caller (CID#1) --> Twilio Trunk --> PBX --> Twilio Trunk -> Cell phone (sees CID#1) However a caveat is that CIDs from calls originating from non Twilio trunks as well as from internal extensions should not be spoofed (or can't be spoofed). I'm uncertain about how to configure trunks properly for this scenario. Any ideas?
  9. cwernstedt

    Calls Routing/Redirection

    I have a similar problem to the one discussed above. I need to differentiate between calls coming in on two trunks to the same provider (Twilio). One trunk as defined on the Twilio side enforces TLS at extra cost, but I don't want all incoming calls from Twilio to go via this trunk. Is there a way that I can make the PBX route Invites like the two below to different trunks? Invite version 1 (I want this to go to the first trunk): Invite version 2 (I want this to go to the second trunk)
  10. cwernstedt

    One way (or no) sound for clients connecting with VPN

    As it turned out, I had forgotten to put in all of the local networks in the IP Routing list under SIP settings. Like this: (covers all private address spaces) 10.0.0.0/255.0.0.0/[PBX private IP address] 172.16.0.0/255.240.0.0/[PBX private IP address] 192.168.0.0/255.255.0.0/[PBX private IP address] 0.0.0.0/0.0.0.0/[PBX public IP address] The amazing and puzzling thing is that things worked at all from misc networks in the 10.0.0.0- series before this change.
  11. 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
  12. cwernstedt

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

    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.
  13. cwernstedt

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

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

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

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