davidav
-
Posts
27 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by davidav
-
-
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 agree that the installation is not as smooth as it should be. Leaving the HTTP and LDAP ports set at the standard is somewhat daft since it can prevent the PBX from starting at all. The information about this and how to fix it is available, if you search for it, but that shouldn't be necessary. I run ports 81 and 390 to avoid this issue, but why not make those the defaults, then at least it would start. If those are not ideal for you, you can then change them in the web interface. Just make sure that the install notes make it plain what is the default HTTP port.
There is of course the question of why the PBX wants to bind to the LDAP port anyway. It's not an LDAP server so it shouldn't be doing anything of the sort.
The free version of snomONE is restricted to 2 NON Snom registrations. I believe the next level up (paid for) raises that to 4. I guess the top level, no holds barred has no such limit, as is the case for the pbxnsip version. I have railed against this on the forums, but to no avail. I can see how they want to protect the market for their own hardware, but they don't even allow softphones, which is stupid as Snom don't make one themselves. But as I said, I can see why they don't want to provide a free PBX to use with their competitors phones and so I think you either need to find a different PBX, or pay for pbxnsip.
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 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.
-
Well, the PBX received a BYE after 37 seconds:
[7] 2010/11/05 13:10:00: SIP Rx udp:10.0.1.21:5060:
BYE sip:11@10.0.1.9:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.1.21:5060;branch=z9hG4bK-bae30358
From: "Office" <sip:11@10.0.1.9>;tag=6b78760386b6280ao0
To: "Study" <sip:10@10.0.1.9>;tag=3a2a4e313b
Call-ID: 1f329437-b0ed7f66@10.0.1.21
CSeq: 103 BYE
Max-Forwards: 70
Authorization: Digest username="11",realm="10.0.1.9",nonce="719cfa3acbaaf7b9c38bb0ce467a6112",uri="sip:11@10.0.1.9:5060",algorithm=MD5,response="7bc669e8becca87f166b785d11fdafbf"
User-Agent: Linksys/SPA942-6.1.5(a)
Content-Length: 0
I am not sure why the phone would initiate a hangup. It looks very "beautiful" from a signalling perspective. Maybe the hook switch is instable or some other hardware defect causing this issue? Is the problem related to a specific phone?
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?
-
Codec negotiation can be a headache in the some deployments. The issue is that many vendors/providers advertise that they can do many codecs for a call. But only few really switch to the codec that was on the RTP stream if there is a codec change during the call setup. That is why we see these issues.
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.
-
Is there any chance you can try another service provider or a PSTN gateway, just for the sake of nailing down where the problem is? I dont think that hangup depends on the codec type.
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.
-
Looked at the log file and seems like the call is being connected on the hunt group party/agent 11. The issue may be that the caller is doing PCMA and the PBX is doing PCMU. If you think your system should be doing PCMA (mostly outside the USA), then please setup the system accordingly (Admin->System->Ports page change the order of codecs and/or the trunk page change the order of codec. This change generally does not require a restart of the PBX. But just start with a clean slate restart the PBX after the changes are made)
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?
-
There are two topics: Media and signalling (SIP).
As for media, it is usually safe to use to use loose RTP routing. The IETF defined something very NAT unfriendly with the usage of the RTP ports and usually no vendor is so strict. You can do this on trunk leven, but also for the whole system (in the admin/ports section).
As for signalling, yea the other big topic is on how to "say who you are" when using trunks. The conflict is the indication of the caller-ID and the other thing the indication who pays the bill. This is a big mess when it comes to SIP trunking. IMHO the RFC says that the From-header contains the caller-ID that should be displayed on the screen, and the P-Preferred-Identity (or Asserted-Identity) says who will pay the bill. Unfortunaly there are is a lot of free software out there that thinks the From is the one who pays and then other headers like Remote-Party-ID will say what the caller-ID is. It gets even worse when service providers don't use session border controllers, because then it mixes even more when the SIP proxy and the PSTN gateway use different interpretations! That's why we added this drop down to give you several choices. I know it is bad, but you have to play with this setting until it works. The next release will make it even more flexible, because this is really a problematic point with the SIP trunking today.
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.
-
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.
-
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.
-
In the screenshot i notice that ONLY stage 1 is used, could you try using all stages before it goes to Final Stage !
for example:
Stage 1 10 11 10
Stage 2 10 11 10
Stage 3 10 11 10
Final Stage 820
Good Luck !!
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.
-
Can you verify if you call extension 20 directly (not through the hunt group), goes to the voicemail?
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)
-
Ok, this may be the issue with the version you are using. Please try the new Mac build (Please make a proper backup of the PBX before using this version - as this is still in the test phase)
http://pbxnsip.com/protect/pbxctrl-darwin9.0-4.2.0.3899. This is not an installer.
Please follow the steps below, if you are not familiar with upgrading
The default working directory is /usr/Applications/pbx. This is where all the configuration files reside.
The PBX binary is by default in /Library/pbxnsip folder.
You need to copy the new binary (pbxctrl-darwin9.0-4.2.0.3899) to this folder & then follow these steps.
* chmod a+x pbxctrl-darwin9.0-4.2.0.3899
* sudo /Library/StartupItems/PBX/PBX stop
* rm pbxctrl-darwin9.0
* ln -s pbxctrl-darwin9.0-4.2.0.3899 pbxctrl-darwin9.0
* sudo /Library/StartupItems/PBX/PBX start
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?
-
I set it up again same as your example and same result, ie. does not divert to voicemail. I have attached a screenshot of the Hunt Group setup. Following is logfile extract.
[1] 2010/07/28 08:01:09: UDP: TOS could not be set
[1] 2010/07/28 08:01:09: Last message repeated 2 times
[5] 2010/07/28 08:01:09: Identify trunk (line match) 2
[7] 2010/07/28 08:01:09: Set packet length to 20
[6] 2010/07/28 08:01:09: Sending RTP for call-F18C78FA-507C-2D10-0D14-1B352@58.96.1.1#88b1ff4703 to 58.96.1.2:55110
[5] 2010/07/28 08:01:09: Domain trunk Silvereye VOIP@server.silvereye.local sends call to 72 in domain server.silvereye.local
[7] 2010/07/28 08:01:09: Hunt Group 72: Moving to next stage
[7] 2010/07/28 08:01:09: Set packet length to 20
[6] 2010/07/28 08:01:09: Send codec pcmu/8000
[7] 2010/07/28 08:01:09: Hunt group 72 started 3 calls
[1] 2010/07/28 08:01:09: UDP: TOS could not be set
[1] 2010/07/28 08:01:39: Last message repeated 6 times
[7] 2010/07/28 08:01:39: Hunt Group 72: Moving to next stage
[7] 2010/07/28 08:01:39: Hunt group 72 started 0 calls
[7] 2010/07/28 08:01:39: Hunt Group 72: Moving to next stage
[7] 2010/07/28 08:01:39: Hunt group 72 started 0 calls
[7] 2010/07/28 08:01:39: Hunt Group 72: Moving to next stage
[1] 2010/07/28 08:01:39: UDP: TOS could not be set
[1] 2010/07/28 08:01:39: Last message repeated 2 times
[7] 2010/07/28 08:01:39: Call b6c25adb@pbx#1373951105: Clear last INVITE
[5] 2010/07/28 08:01:39: INVITE Response 487 Request Terminated: Terminate b6c25adb@pbx
[7] 2010/07/28 08:01:39: Call a81a50fd@pbx#1854196564: Clear last INVITE
[5] 2010/07/28 08:01:39: INVITE Response 487 Request Terminated: Terminate a81a50fd@pbx
[7] 2010/07/28 08:01:39: Call 8a818820@pbx#905683506: Clear last INVITE
[5] 2010/07/28 08:01:39: INVITE Response 487 Request Terminated: Terminate 8a818820@pbx
[6] 2010/07/28 08:01:39: Send codec pcmu/8000
[7] 2010/07/28 08:01:39: Call b94e448a@pbx#1776389491: Clear last INVITE
[5] 2010/07/28 08:01:39: INVITE Response 487 Request Terminated: Terminate b94e448a@pbx
[5] 2010/07/28 08:01:42: SMTP mail.silvereye.com.au: Alert(1, 0)
Mac OS Sierra
in MacOS related topics
Posted
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.