Vodia PBX

Everything is in Eastern time zone (US east coast). We are trying to cover times outside the 9-5 and Monday to Friday as good as possible.

Please check after you login to snomone.com under your account what licenses you have. It is not enough just to set up a system, you must also have a bundle associated with it. If you want to use the free version, you have to put that one in the cart and then check out. Then after completing the checkout, you should see the bundle under your system in the account/license page.

The reason was that practically every service provider out there reads the RFC in a different way and a simple drop-down was not enough to cover the cases. Most service providers assume(d) that you are registering a soft-phone with exactly one phone number associated, and when it comes to cell phone inclusion and you want to see the phone number of the one who actually called in, things get very messy.

Hmm in version 5 you actually don't have to change the setting in the pbx.xml file. Any chance to get (in a private message) the whole PCAP?

I think this problem is not related to Lync, it is the general question on how the PBX knows where to send the call. You might have to just enter something in the "send call to extension" on the trunk (see http://wiki.snomone.com/index.php?title=Inbound_Calls) or make this field blank.

500 calls are not possible today (as far as I know what processors are out there). I would say the limit is 250 calls today with the best processor that you can get. Yes, the key is partitioning into domains. Once that is done, you have to think of calling from one company to another (one domain to another), using the dial plan. In order to avoid going through PSTN for money, you can bypass that with gateway trunks. If you have too many servers, it makes sense to use a SIP proxy as intermediate (10 server would result in 90 routes, 100 servers into 9900 routes). We added the possibility to represent the dial plan in text form, so that it is easier to copy & paste it into several servers. When it comes to server specs, my recommendation is to go for mainstream servers where the price/performance ratio is the best. You need only two cores for a server and 8 GB of memory is also okay unless you want to keep a huge CDR history in memory. Hard-drive requirements are low, you can go for a SSD to lower the risk of a hard drive crash (unless you want to record all phone calls). There is no hard number that I can give you, because the call capacity depends on so many factors. But as a rule of thumb I would say a mainstream server like that is good for 100 calls, and if you users are 25 % busy on the phone that means that you can have around 400 extensions on such a system.

Yea, that's a "classic" for the upgrade to 4.5 and higher. That was a side effect of having more control over the SIP headers. You need to change the header presentation in the trunk. There are actually some posts on the forum about this. I would suggest to try the few standard cases out which are available in the drop down (Remote-Party-ID, RFC3325, ...); usually one of them works with your service provider.

The phones have nothing to do with that, except that you can control the redirection through the phone user interface (when using plug and play with the PBX though the menu button). snom ONE mini includes it, as it includes the snom ONE software. However there are differences between the version that is shipped with the mini (version 4) and the current version, which is version 5. Version 4 also includes cell phone inclusion, but not to the extend that version 5 does.

Nothing from the PBX. This must be something from the underlying hardware.

It is in the pipeline, but not at the top yet.

Yes. Some people call this "scaleability", especially those who have a TDM PBX with 16 connectors for handsets.

Yes. If you look into the redirection settings on extensions, you can find the settings for the cell phone inclusion. There you can also select if the user has to answer the phone by pressing a DTMF tone, this avoids the call to roll into the cell phone mailbox. You can also include more than one cell phone, as this is becoming a reality today with many users. And you can select the times when the cell phone inclusion should be done, so that users are not called in the middle of the night. Last not least you can include cell phones also in hunt and agent group calls.

Not sure if I got this right, we don't support XMPP yet...

We have many customers that have between 100 and 200 customers. We even have customers with 500 extensions on it. And there is even a system that we are aware about with 1700 extensions on it. There are two essential factors that you have to keep mind. The first one is how active these users are. For example, a call center with the agents connected 80 % of their time generates a lot more traffic than an engineering company where the employees pick up the phone one or two times per day. The installation with 1700 extensions has most of them not even registered most of the time, so that is why that number is okay. The next factor is obviously the hardware that is in use. While the PBX always bind to one core, it does make a difference if you take the latest server CPU with xxx GHz, cache, DDR3 & Co or a snom ONE mini. With the mini as a rule of thumb you can have ten calls, while on a modern server you can have 150 concurrent calls. I you want to reach higher numbers, you have to split the installation up into several domains. Usually if you have large company clients, it is relatively easy to identify departments that from a PBX point of view, work independently. Then you can work with gateway trunks so that they can call each other with extension numbers.

Yes it would be great to see the PCAP. Please send me a private message.

Lync in office 365 behaves different than the typical Lync setup when you do this in your company. The point is that Lync 2013 is supporting XMPP, so that all those tricky workaround to get Lync working are becoming superfluous. Not sure how quick Office 365 will switch to the XMPP-based presence, but our approach is to support XMPP instead of the Lync 2010 presence.

Hmm. Any chance that the two PBX can send packets directly to each other, for example through a VPN? Edge devices are complex and it is easy to make mistakes.

Well that log is from the phone, that probably does not help much. The question is how the systems are connected. Are they able to "see" each other, meaning can they send packets to each other directly or is there NAT involved?

ntp.snom.com has the problem that it advertises both IPv4 and IPv6 address. If you mini has no IPv6 access, that might lead to the problem that the NTP will try for a long time the IPv6 address. It would be great if ntp4.snom.com and ntp6.snom.com would be available as well, but it is not. So maybe you just pick something like pool.ntp.org or the time server of your choice.

I would definitively recommend to move to 4.5.1. There are several known issues with the releases before 4.5.1 which can take the service down. There is a checklist for upgrades on http://wiki.snomone.com/index.php?title=Upgrades what needs to be done to successfully move to 4.5.1.

Looks like in 20 calls the problem will be solved... Those old CDR entries should be disappearing. If you want to force it right now, remove them manually and restart the service (e.g. /etc/init.d/snomone restart). If you restart the whole system, make sure that it gets the time right!

Well, the service should never go down. Having another server does not solve the problem, as it will probably expose the same behavior. If you are on version 4, I would suggest that you upgrade to version 4.5.1 which includes a few critical bug-fixes. Otherwise, you should open a trouble ticket with us and we need to find out what the problem is.

If you look in the file system, is there anything happening in the cdri/cdrt/cdre folders?

So the log messages on the PBX are also in the year 2013? It might take a couple of calls until the CDR are getting back in line.

Okay, that is kind of good news. I assume the problem is that the PBX is in the year 2106, in other words: in the 70s. So you see only the "recent" CDR. Can you login to the SSH level and enter this: date -s 2/4/2013. If that changes the behavior, the problem is somewhere int the startup when it tries to get the time.