Jump to content

Vodia PBX

Administrators
  • Posts

    11,135
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. To get to the bottom of the problem you must look at the INVITE packet which is sent to your SIP trunk provider. Unfortunately it seems that every one reads the standard a different way. You might have to consult the providers documentation on how they want it and even if they support it at all. If the provider is on our drop-down list, it would be great to know if we can improve anything on the header side to make the experience for other users smoother.
  2. I cannot imagine how the opening of the extension for provisioning can be related to the soft phone registration. I would try to get a native PCAP (not inside the PBX, but using Wireshark filter by the IP address of the phone) to see if there is something going on that we should know about.
  3. Try to set the log level for the webclient to 9 and see if the PBX can properly communicate with the RPS server. Maybe the large number of requests are a problem so that it does work when you just do one extension, but not when you do bulk.
  4. In the replacement, put the \1@domain (not sure could also be sip:\1@domain); the \1 will match the pattern.
  5. It might actually be time to get this going. Maybe the IETF meeting in Berlin should be the deadline for having this done.
  6. I would use Wireshark (tshark) tcpdump filters can be difficult.
  7. There is a setting in the domain which controls the "DISA" (that is the name of the feature) flag. Check "Use extension ANI for DISA" in the domain settings.
  8. Tried to reproduce the problem... No luck. How did you pick up the call, on the cell phone? Did you have the agent press "1" to connect the call? Maybe you can just give us access to the system, so that we can understand the setup.
  9. Ehh ja the problem is that there are two conflicting entries in the phone. The CAN-5 is using an internal table from the phone (built-in and hard coded with the firmware), while the PBX provisions a rule that is independent from the firmware. Any reason why you don't use the one automatically generated from the PBX? Is CAN-5 different from the East Coast US time?
  10. CAN-5? Did you add that yourself? I am not aware about that value in the time zones file. The dst settings look ok to me, but maybe the zone is confusing the phone.
  11. I actually just checked with a phone over here: <utc_offset perm="RW">-18000</utc_offset> <dst perm="RW">3600 3.2.7 2:0:0 11.1.7 2:0:0</dst> That looks like it should, at least as far as I understand those numbers.
  12. Trying to understand how to read that date, but it seems this is really February 3rd (because November 6 is obviously the end date). This is what is in there for EDT: <zone name="EDT"> <description>Eastern Time Zone</description> <gmt_offset>-18000</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>3</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>2</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>11</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>1</dst_stop_week_of_month> <ampm>12</ampm> <snom>USA-5</snom> <yealink>United States-Eastern Time</yealink> <grandstream>EST5EDT</grandstream> </zone> What do you see in the "generated" folder for that phone? The time zone entry clearly shows March, it is hard to imagine that this changes to February somehow.
  13. DST should change next Sunday if I am correct... Maybe the problem is related to that because the phones have a week off? Although that would not explain why it is correct after starting up.
  14. How can we make sure this is not a bug on the snom phones? If they have the right time after the boot up, well that cannot be a coincidence. How do you refresh? Sync the extension from the PBX web interface?
  15. The login banner will only work if the URL in the browser window matches the name of the domain. This can be kind of tricky because the user has not logged in yet and the PBX needs to guess the domain name.
  16. The documentation is now mainly on http://vodia.com/doc, there is something about the loopback on http://vodia.com/doc/domain_dialplans Did you "Try Loopback" in the dial plan? If you disable the loopback detection in the global settings, that should work well. In the latest 5.4 we have also included that you can use ext@domain to send calls to specific domains. That way you can avoid using long prefixes.
  17. Yea we have made a 5.4.0a image that seems to solve that problem. It is not really clear what caused it, but it seems to solve it. The same is true for MacOS.
  18. Do you see that also in the PBX log for email (log level 7 at least)? What are your settings for email? Did you put 127.0.0.1 there or "localhost"?
  19. LoL I think when we made 4.5 Yealink was widely unknown.
  20. No. If you take a peek at the Yealink LDAP documentation, you will soon come to the conclusion that your LDAP scheme does not work there. Please use PnP, at least just to see how it works. We spend a lot of time on getting PnP working, and repeating the whole learning curve here on the forum would cost us all a lot of time. Once you get it working with PnP, you can start tinkering with the parameters if you have to.
  21. The installer itself is fine; surprisingly easy ;-) It is the PBX image it self that has some weird behavior. We have had a couple of compiler warnings with the updated tool chain; fingers crossed that the new thread local storage is not causing any problems on MacOS...
  22. You can formulate queries in LDAP pretty much with the standard patterns. All queries are always handled inside the domain (using the authentication information). Because it is a common problem in LDAP to create expensive table scan, the PBX takes the liberty to break a query after 100 ms or so, in order to give the CPU also to other domains. The queries are matches against the user and domain address book and the extensions of the domain.
  23. The country code helps the PBX to "translate" numbers into numbers starting with the + (global numbers). That is why we are so pushy to use the country code. Without the country code, in theory you can also get it working but it a lot harder.
  24. You can always enter numbers starting with +, e.g. +972123456 then the PBX will understand that the digits after the + are the country code
  25. Approved we have made 5.4.0 now which should have a clean build including the .dat file. The a-z versions are usually just snapshots from the master branch.
×
×
  • Create New...