Jump to content

davidav

Members
  • Posts

    27
  • Joined

  • Last visited

davidav's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. When do you plan to have a version tested on Mac OS Sierra? We had to abort upgrade to Mac OS Sierra and roll back to El Capitan back in November because we couldn't get the Vodia PBX to work on it. Can't recall detail of issues, but I know that System Integrity Protection (SIP) caused installation problems with a number of other software packages.
  2. We've previously setup and managed trunks through the admin console but now can no longer get to the screen to view or update settings. Clicking on the VOIP Providers option under Trunks just brings up a blank page. Any ideas or suggestions?
  3. we have 5.4 running on OS X El Capitan but just realised that the audio files must not have been properly installed - callers hear no beep after the recorded message for voicemail. I looked in the pbx folder and can't see any audio files nor can I work out how to install from the admin console. How do we install the missing files?
  4. Setting up Snom One on another Mac Mini. The Wiki is still wrong for stopping & starting pbx on OS X. Correct commands are: unload -F /Library/LaunchDaemons/com.vodia.pbx.plist load -F /Library/LaunchDaemons/com.vodia.pbx.plist
  5. I already did this before logging the issue. The pbx.xml file has been updated to include: - <ip_http_port>81</ip_http_port><ip_https_port>444</ip_https_port> This change enabled me to access the pbx admin console on port 81. The problem is that I can no longer access the OS X web server on port 80 (or on the default port which I assume is also 80). I also changed the LDAP port just in case that was causing an issue. PS. Can someone please also update the Wiki (http://wiki.snomone.com/index.php?title=Restarting_the_System) to provide correct instructions for stopping & starting the pbx on Mac OS X. I found several other forum posts on this and it seems that the software has been updated to use current auto-start process on OS X but the documentation on the Wiki is out of date (StartupItems are clearly no longer used) and I couldn't find anything with correct instructions on how to manually restart the system, leaving a full OS X restart as the only option (not desirable when server is running other services).
  6. I am reviving this topic because upgrade to OS X Yosemite has created a new problem. I can run the Snom One admin console at http://localhost:81 (changed port per above) but after installing Snom One I can no longer access the OS X Server's web server. The Websites service in OS X Server (Yosemite) appears to point apache to its own configuration files so maybe the Snom One admin console is starting apache and interfering with OS X Server's website configuration? Has anybody managed to get Snom One and OS X Server (Yosemite)'s Websites service running together? Any ideas?
  7. Admin console on OS X Yosemite

  8. I have paid for pbxnsip, hence my request for a new build of the pbxnsip version (instead of the snom ONE version)!
  9. Spoke too soon! The .3959 build has a snom ONE branded administration console and it appears to not allow any non snom phones (message in log is: "3rd party registration licenses exceeded (1 > 0)". We use Cisco phones so this build is no good for us nor anybody else in a mixed or non-snom environment. We have paid for a pbxnsip licence so can we please get this fixed urgently.
  10. I have just wasted an entire day trying to get pbxnsip to install on Mac OS X 10.6.5 Server. When I finally came across this thread on the forum I was surprised (and relieved) to discover that I was not alone! Clearly the Mac OS X build on the pbxnsip downloads page (pbxctrl-darwin9.0-4.2.0.3958) does not work for OS X 10.6.5 Server (the current version). When I replaced with the 3959 build it did work (subject to caveat below) - frustrating that this build is currently only to be found, buried away in a reply to this thread on the forum. The caveat for me was that when I installed the .3959 build I hit another error (logged in pbx_startup_err.txt) - "FATAL: Could not open TCP port 389 for HTTP/HTTPS" I searched the pbx.xml configuration file and found: <ip_ldap_port>389</ip_ldap_port> I have no real idea what this is or what the implications of changing it are, but I changed 389 to 390 and finally got pbxnsip to start (30 frustrating hours after starting install!). We are running a vanilla install of OS X 10.6.5 Server. We have been running pbxnsip for about 3 months and only hit these problems because for other reasons I had to do a complete reinstall of the OS. To avoid other poor souls having to go through all this, hopefully someone from snom/pbxnsip will read this and: 1) remove the .3958 build 2) replace with .3959 build and change the config file in the install package to avoid the ip_ldap_port problem. 3) as I've posted elsewhere on this forum the config file should also really default the ip_http_port to 81 or something other than 80 because I suspect that most OS X Server users will also be running the webserver which comes as a standard component of OS X Server and which takes port 80.
  11. I don't believe the problem is related to a specific phone - we have experienced outbound call dropouts on both of our Linksys SPA942 phones (very common phone) and also using a softphone. I can switch the phones to verify and/or try again using the softphone. Not sure what a "hook switch" is?
  12. Thought it was too good to be true. We are now back to a few good outbound calls but many dropping out. I have attached the log for a typical sequence. Three outbound calls were made to the same number in quick succession: the first two dropped out and the third time the call was OK. The log has the trace for the second and third calls, ie. one good, one bad. Hopefully the comparison of trace for a good and bad call to the same number will help shed some light on this mystery. Good_BadCalls.rtf
  13. Maybe you were onto something with PCMA - I changed so this is preferred codec for the trunk (1st in list) and inbound calls can hear ring tone and only had one dropped outbound call yesterday (which could have been because phone was set to PCMU as preferred - now changed to PCMA). Too early to say that its working because it was a very quiet day in the office here but we'll monitor closely over next couple of days and report back on status. I thought I'd tried all possible combinations of these three settings (codec, strict RTP routing & remote party/privacy indication) but must be that I missed this one. None of this anyway makes a lot of sense to me - I can see that PCMU is still being chosen for some/most of calls anyway but some calls are connected with PCMA. If yesterday's success holds for next few days I will analyse to see if there is any obvious pattern or logic to actual codec selection.
  14. I have tried PCMA and G729A as alternatives but neither seem to work any better. I have made PCMU the first choice because this seems to be the codec most often selected by inbound callers - most calls now seem to have PCMU at both ends and this seems to have eliminated the "transcoding" messages we were getting on most/all calls before. I have assumed that RTP Pass Through is better than transcoding?
  15. The problem is that it doesn't work. I have not been able to find any combination of settings that will allow us to have inbound and outbound calls on the same trunk. Surely this is a pretty basic and common requirement? It seems like we need the Strict RTP Routing setting to be ON in order for incoming callers to hear a ring tone - is this what you expect or is there some other setting we need to change to overcome this? Because it seems that we need the Strict RTP Routing setting to be OFF in order to make outbound calls which don't drop out after approx 30 secs - is this what you expect or is there some other setting we need to change to overcome this?
×
×
  • Create New...