Vodia PBX

Is the file system full?

That's happening when you restart the service in Linux (not related top Lync). The sockets are not available immediate, but after one minute or so the PBX is able to get the ports.

well if you log in to the web interface as administrator and go to the system status, there is information about how many calls are active and how many calls are in the license. That should help to solve the problem.

Do you have any "dangling" calls? What does the admin status web page say (any calls active, how many calls in the license)?

I think for right now, the easiest solution is to disable the ALG. TLS is practically not supported by the SIP service providers (sad but true).

A little bit hard to say out of context, but I assume that the call needs a license for G.729A which is not included in your license.

The documentation for click to dial is at http://wiki.snomone.com/index.php?title=Click_to_Dial.

Yes, that is the problem. The hardware has no MAC. Maybe your hosting provider has a venet option, which has a MAC. For hosting purposes we provide a different kind of license that is bound to the IP address of the server, not sure if that's an option for you (this is a rental model). If you want to host for third parties, you would have to go this route anyway as the CPE licenses don't support hosting.

LoL. Yes in theory the ALG should be transparent. But we had to find out that many SIP ALG vendors act after the motto "if I don't understand it, I'll block it". That is where TLS comes into play. TLS has the advantage that the ALG has no chance to see the SIP packet and start messing with it. The ALG does not have to patch the packets for snom ONE anyway, as the SBC does all neccessary steps to deal with devices behind NAT. Bottom like: Use PnP for phones as much as possible. If you use the automatic provisioning, the PBX will set the phones to use TLS anyway (well, for snom phones). Then the ALG will be taken out of the picture.

I think the problem is that there is no IP address and no MAC. Seems like there is no suitable Ethernet interface. What OS is this? In Windows what does ipconfig say? In Linux what is the output from ifconfig?

There can be other reasons: Did you set CO-lines on the trunk? Then you might just have to add more. You can also limit the number of calls per extension ("lines" under the registration tab) You may limit the number of calls in the domain (on admin level don't click on the domain link, instead click on edit) And you can set the max number of calls in the system in the admin settings I guess you did not change the performance threshold cutoff (the blue line that you see in the CPU usage graph on the status screen), which is by default at 75 %

To uninstall the service: chkconfig --del snomone rm /etc/init.d/snomone To remove the files: rm -Rf /usr/local/snomONE

Well, SIP is no HTTP; you need two different ports for that. On which port are you running SIP and on which port HTTP? Maybe that got mixed up.

There needs to be a timeout (this is a feature), for example if you do click to dial and land on the cell phone providers mailbox you don't want to record two hours of silence.

No this was more interesting for the snom ONE roadmap--in the long run, it will be enough to support only XMPP and there is not more need to do tricky interoperability with Lync.

It is possible. Some tips/comments: For calling each other, I would use "real" PSTN numbers; but instead of sending them to the gateway you can make entries in the dial plan that send the call directly to the other branch office. I would put them into a network where they can send each other packets without NAT. For example if you create a VPN that should be easily possible. Because the snom ONE mini are just running Debian Linux, you can for example install the OpenVPN client on the system. Then you can set up gateway trunks between the system, so that they can call each other without having to go through the PSTN network. The alternative is to have one central PBX and then just register the phones to that one system. That simplifies the setup (dial plans, trunks, etc) and it becomes possible, for example to pick up calls from other offices. if you put the branch offices into a VPN you could even keep local PSTN gateways for terminating on-site.

That sounds more like a license limitation. What are you using?

There were some bugs in 5.0.4, especially after getting the first feedback from ActiveSync we thought that we should do this release quickly before any more new features will make a release difficult.

As far as I can tell we only tested with Lync 2010. Rumor has it that Lync 2013 includes XMPP, which would be a much easier way to publish the presence state.

If you put just the IP address there, then the SIP packet will be sent on UDP transport layer (wasn't our idea, check the RFC). However Lync does not support UDP. Try something like sip:192.168.1.2:5060;transport=tcp. But you might have to use DNS, if the Lync server does not accept the IP address as the destination address.

At first glance, it looks like we are hitting this problem: http://msdn.microsoft.com/en-us/library/dd923737(v=office.12).aspx but the question is why is the endpoint not registered. The PBX should keep the registration actually alive. If would be interesting to see the 200 Ok on the registration, if it contains any information how long the registration is valid and if the PBX needs to take some special MS action.

That sounds to me like the OS is blocking the traffic because it thinks this is a security thread. If you can run Wireshark you will see quickly what is happening on the network layer and if the packets are leaving the system or not.

In general, VoIP is much more difficult to predict that TDM. We use to compare the question to "how many emails can I send out with my email server per minute"--it depends. Anyway, we have made some tests. With G.711 and nothing special we were actually able to get 30 calls going. That would be the "optimistic" case. In a more pessimistic case we got 10 calls working, where the G.729A had to do the transcoding. But there are even more pessimistic cases, e.g. call barge in to a call which is being transcoded and recorded. Also, the PBX has a mechanism that rejects more calls when the load gets too high (not only for the mini). This should make sure that existing calls do not suffer when the system gets into overload. As a bottom line, the mini is good for 10 "regular" calls. If you have a busy system, then your should consider using a standard server. You can try with the mini, and if you are experiencing performance problems you can backup your configuration and move it to a server.

No the performance is not the point. This looks like a keep-alive problem. Can you put the IP address of the Lync server into the SIP logging field, so that you can see all traffic between the PBX and Lync?

Windows 8 on the PBX or on the client? Anything with the personal firewall?