davidav

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.

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?

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?

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

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

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?

I have paid for pbxnsip, hence my request for a new build of the pbxnsip version (instead of the snom ONE version)!

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.

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.

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?

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

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.

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?

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?

I have discovered that we seem to get more success with outbound calls when I change the "Strict RTP Routing:" setting for the trunk to No. This had defaulted to Yes but I read in the Admin Guide that it recommends setting it to No. The attached GoodCall trace shows that there is more chatter immediately after the call is established - in the dropped calls we never saw all the chatter around "Clear last INVITE" and "Determine pass-through mode after receiving response". Problem now though is that the price of getting outbound calls working seems to be that inbound callers now hear no ring tone. The behaviour of inbound calls seems to be changed by changing the "Remote Party/Privacy Indication:" setting for the trunk: - if it is set to "No Indication" (the setting we have always used) then the caller hears no ring and nothing at all once answered although the person answering can hear them talk; - if it is set to "Remote-Party-ID" then the conversation is audible at both ends - but there is still no ring tone for the caller so they will assume that the number is incorrect/not working unless its picked up immediately. - none of the other options work as well (!!) - with some neither party can hear each other and with others the call only rings once or twice before being dropped - and the ring tone is still inaudible to the caller in all of these settings. See siplogs attached for more information. GoodCall.rtf InboundNoRing.rtf

Call logs attached for two dropped calls. Today it is happening on every single outbound call. The two logs are for calls made on each of the two trunks we have setup - same result on both. DroppedCall1.rtf DroppedCall2.rtf

We are suffering a lot of pain with outbound calls dropping out - happens pretty regularly but not with every call - probably about 30-50% of outbound calls. I have no real idea why this is happening - we have tried all sorts of things to improve but generally 1 step forward, 1 or 2 steps back. Looking at a trace for a dropped call today (a normal VOIP call to a PSTN landline), there are two things that look suspicious: 1. We always seem to get the following "falling back to transcoding" messages when the call is initiated: [7] 2010/10/19 14:55:58: Set packet length to 20 [6] 2010/10/19 14:55:58: Sending RTP for 4f3c17cb@pbx#1193819909 to 58.96.1.2:59256 [7] 2010/10/19 14:55:58: 4f3c17cb@pbx#1193819909: RTP pass-through mode [7] 2010/10/19 14:55:58: 60f323f4-684b9d07@10.0.1.21#510adaefc6: RTP pass-through mode [7] 2010/10/19 14:55:58: Cannot pass through on 60f323f4-684b9d07@10.0.1.21#510adaefc6, falling back to transcoding [7] 2010/10/19 14:55:58: Cannot pass through on 4f3c17cb@pbx#1193819909, falling back to transcoding [7] 2010/10/19 14:56:40: SIP Rx udp:10.0.1.21:5060: 2. Just before the call dropped out, there is the following mysterious entry in the log. Why is it trying to connect to 173.166.177.221?? A quick whois search suggests this is something to do with commcast. [7] 2010/10/19 14:57:00: Last message repeated 7 times [3] 2010/10/19 14:57:00: Could not connect to 173.166.77.221:443 [1] 2010/10/19 14:57:00: Could not send via TCP: 0 bytes [7] 2010/10/19 14:57:03: SIP Tr udp:58.96.1.2:5060: Any ideas on either of these issues?

Mac OS X installation is a little tricky because there is currently no installation package (wiki installation guide for OS X refers to an installation package which is not currently available) The Mac OS X instructions should probably also stress more clearly the need to change the port for the pbxnsip admin console. It runs as its own webserver and most OS X Servers will already be running the preconfigured webserver on port 80. I changed to port 81 and can now logon to the admin console - by using url: http://localhost:81.

With Pradeep's help we have found the solution. For some, as yet unexplained, reason our voip provider appears to be cancelling the call after 30 seconds if no answer. It looks like the 30 second delay in the hunt group just happened to coincide with this and hence the call was getting dropped before the transfer to voicemail. Once we set the delay to 29 seconds, the transfer to voicemail happens correctly. I did test with different delays earlier but we also had other problems with the setup at that time which I guess must have been masking the problem. On a more general note, the process of setting up pbxnsip has surfaced a number of underlying issues with our voip connection which must have been there for a while but which were not so obvious with our previous ip pbx system. I have a few yet to solve, but we have a workable system now and whilst pbxnsip seems to be pretty unforgiving of voip setup issues, the siplog reporting is excellent and the more I learn about/from its reporting, the closer we get to ironing out all the annoying little wrinkles in our voip connection.

Worth a try but I tested and it doesn't work I'm afraid. When I went back and checked the manual I can see that it shouldn't work anyway because you are apparently not allowed to use the same extension twice in a hunt group sequence, ie. at each stage you have to go to different extensions.

yes, I've tested that - goes directly to voicemail - tested by putting 820 in the Send Call to Extension field for the trunk (see earlier post)

Upgrade installed and is running fine, but it has not resolved the problem - transfer to voicemail in hunt groups is still not working.

If I dial 20 I get automated response saying "no answer to your request" because 20 is not a "real" extension, ie. it isn't setup to ring anywhere. If I dial 820 it goes straight to voicemail (at least that works!). But per my previous post, if I put 820 as the Final Stage, it still does not work - call is terminated when it tries to switch to the Final Stage.

same result I'm afraid. frustrating. Is there any other information I can provide to help diagnose the problem here?