Jump to content
Vodia PBX forum


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ndemou

  • Rank
    Advanced Member
  1. I haven't tried to implemented it yet chrispopp -- it will become a priority in about 2 1/2 months :-) Since it interests me (and maybe others) I wouldn't mind looking at the issues you're facing in this forum. BTW it's 16:01:17 UTC now that I'm posting and I'm seeing a big warning above my web-editor: "Your content will need to be approved by a moderator". This may add more lag to the conversation. Do you see the same warning when posting?
  2. Hi, we are considering the free but well regarded service "Let's encrypt" for my PBX certificates. The draw back is that I need to install a new one every 3 months. So here's my question: Is there a way to add a certificate to the PBX from the command line (so that I can automate it with a script)? I'm running the PBX on Linux (CentOS).
  3. We spent quite some time testing v58.2 and we still missed this issue and now it's on production already. We can't rush to upgrade our production system -- what if we hit an even bigger issue? Is v58.2 already not supported? Apart from upgrading we only changed a few colors in the CSS and did some light customization of unrelated web pages (header, footer, email). I'm not 100% we tested without that customization but I think we did on the test environment -- I will verify it. Not sure if I understand you fully here but I should note that we tried both versions (v5.5 and v58) many times and we were always checking the results from the same client PCs and the same browsers.
  4. Adding a screenshot from v5.5 for comparison
  5. We've upgraded yesterday from v5.5 to v58.2 and one of our clients noticed that there are no ACD statistics on User Portal > ACDs (see screenshot). We also tested v59.0 which has exactly the same issue. We depend on the availability of SIP History Info support so we can not go back to v5.5. We urgently need advice on what we can do to resolve this issue.
  6. Hi, I was trying to upgrade to 59.1 but this link gives a 404: http://vodia.com/downloads/pbx/centos32/pbxctrl-centos32-59.1
  7. We are using click-2-dial links with embeded passwords like this: .../remote_call.htm?user=123%40domain.com&connect=true&dest=123456789&auth=123%40domain.com%3Asecret I.e. exactly like in the example at https://vodia.com/doc/click2dial but with connect=true added to avoid the message for "please press 1" each time. The problem is that very often the SIP phone automatically answers the phone instead of just ringing and waiting for the user to pick it up (of course this only happens for calls that are initiated by click-2-dial links in all other incoming calls the phone behaves normally).
  8. I always thought UDP was "recommended". Thanks for the tip.
  9. I have a user with a yealink T20P. He can make outgoing calls but he never receives incoming calls. If you call his DID you get a long silence. So I took a SIP trace and I see this: U 2017/06/06 13:33:48.390550 <PBX_IP>:5060 -> INVITE sip:707@ SIP/2.0. Via: SIP/2.0/UDP <PBX_IP>:5060;branch=... From: "Nick Demou" <sip:XXXXX@XXXXXX>;tag=... To: "XXXXX " <sip:+3XXXXX@XXXX>. Note at the 1st line that PBX is sending the INVITE to the private IP of the user ( Here's a REGISTER from the phone: U 2017/06/06 13:11:07.564288 -> <PBX_IP>:5060 REGISTER sip:DOMAIN:5060 SIP/2.0. Via: SIP/2.0/UDP;branch=z9hG4bK1624166643. From: "XXXX" <sip:707@DOMAIN>;tag=3302671109. To: "XXXX" <sip:707@DOMAIN>. Call-ID: 3133434105@ CSeq: 12 REGISTER. Contact: <sip:707@>. Authorization: Digest username="707", realm="DOMAIN", nonce="eb2cd5a3be226b436a84e3c7c35ea1f8", ur i="sip:DOMAIN:5060", response="715336ac4195b8d694e73c12978c42a3", algorithm=MD5. Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, M ESSAGE. Max-Forwards: 70. User-Agent: Yealink SIP-T20P Expires: 3600. Allow-Events: talk,hold,conference,refer,check-sync. Content-Length: 0. The work around I found is to switch the SIP Phone to use TCP instead of UDP. I'm posting this however because I find it a very strange behaviour. Why would the PBX ignore the public IP that it receives the REGISTER from and use an RFC1918 private IP? Is there any setting I could set to tell the PBX that it should never try to route traffic to private IPs (e.g. a list of private networks that are reachable)?
  10. I've created a test domain with only one extension. On the domain I've let the Default IVR language to default system IVR language (Greek). On the extension I've set the IVR language to English and I've configured it to redirect to the mailbox in 1 sec. I'm calling the extension and the mailbox plays the greeting in Greek. I was expecting to honour the extension's "IVR language" setting and play English. Attached is the domain tar file and here are logs from one call: [7] 20170118225343: 277: SRTP tx keys: 7ss+IsgoGb3EvMXnMvrolTW7RfM7GoNswqq31Z+3 85828e46 [8] 20170118225343: Identify trunk (IP address/port match) 1 [8] 20170118225343: Trying to match number +302113110089 with ERE ([0-9]*) [8] 20170118225343: Send call to extension ERE returned +302113110089 [7] 20170118225343: No authentication of call because call comes from trunk [9] 20170118225343: UDP(IPv4): Opening socket on [9] 20170118225343: UDP(IPv4): Opening socket on [9] 20170118225343: UDP(IPv6): Opening socket on [::]:64884 [9] 20170118225343: UDP(IPv6): Opening socket on [::]:64885 [8] 20170118225343: Trying to match number +302113110089 with ERE ([0-9]*) [8] 20170118225343: Send call to extension ERE returned +302113110089 [5] 20170118225343: Port 277: Incoming call in domain xxx.test.z1.vpbx.gr on port 277 trunk TLS01 (1) [8] 20170118225343: Trying to match number +302113110089 with ERE ([0-9]*) [8] 20170118225343: Send call to extension ERE returned +302113110089 [8] 20170118225343: Call state for call object 794820: idle [8] 20170118225343: Port 794820: Disconnect all others except leg 1799756 [8] 20170118225343: Last message repeated 2 times [8] 20170118225343: Port 794820: Disconnect all others except leg 1799756 [8] 20170118225343: Call state for call object 794820: connected [8] 20170118225343: Play audio_gr/mb_you_have_reached.wav audio_gr/mb_leave_msg_after_tone.wav audio_moh/mb_beep.wav, caching false xxx.test.z1.vpbx.gr(1).tar
  11. As part of a migration from v5.3 to v.5.5 we backed up all domains from one server running the old version and restored them to an other running the new version (we couldn't just copy the filesystem because of bugs that were --rightly-- attributed to filesystem corruption). Issues 1,2 Most of our domains use global dial plans but a few have their custom DPs. After restoring we found out that in some lines of some DPs the trunk had been replaced with "Unassigned". The funny thing was that if you switched the DP edit page to plain text mode you would see the correct name of the Trunk and you had to just hit save without touching anything and all was working fine. The Trunk was one of the basic ones we also use on the global DPs and had been defined long before starting the restore procedure. The issues here are two 1) that the dial plan had not been imported successfully and 2) that the failure had not been communicated to us via the WebUI Issue 3 Because of Issue 1 I found myself coping dial plans in plain text format from the old server to the new one and discovered another issue: When pasting a DP with this line (copied from the v5.3 server) 7;vPBX-MainOffice;;5xxx;;;false This specific DP entry was not created from the plain text script. Creating it manually on the the webUI succeeded and gave me the exact same line. Here it is copied from the v5.5 server: 7;vPBX-MainOffice;;5xxx;;;false There are again two issues here, the one of less importance is that this line failed to get interpreted and the one of most importance is that the failure had not been communicated to us via the WebUI. I consider the later issue (silent errors) extremely import. In this particular case the absence of the above DP line resulted in some calls not getting through. So the customer complained, we found out we fixed it and the harm was small. But consider this: we have dial plans were a few lines with high Pref are blocking high cost destinations. No one will complain if the dial plan missed these line until after a beefy bill at which point we'll have to pay for the calls (because blocking them is a contractual obligation). As you can understand we found ourselves spending more than an hour checking DPs line by line (we guessed that such lines will not be eaten by a bug --because they are even more simple that the above-- but we could take the risk).
  12. Upgraded to v5.5.0 and while creating/editing dialplans I noticed that I can only see the first digit of Pref which makes editing and troubleshooting difficult. Here is a screenshot from v5.5.0 And here's one from v5.3.x
  13. ndemou

    No billing email available for domain xxxxx

    Thanks.We don't. If there is any easy way to suppress it please let us know.
  14. For many months I get a batch of errors like this everyday in the logs: "[2] No billing email available for domain xxxxx" except for the messages everything seems fine. Is this anything to worry about?