Vodia PBX

"In theory" it should work... However, couple of comments. 1) I would say, there is a good probability that it works. Not being the biggest Max OS expert I would assume that Mountain Lion is reasonably backward compatible to 10.6.8; at least we did not use any dirty tricks on the OS level to have the PBX working. 2) Probably from a CPU perspective, this would be actually okay as the process is supposed to run in another ring that file services usually do. Also actions like fetching files happen in the PBX in seperate threads that can deal with delay. My worry would be more in network bursts, e.g. when the user stores large bitmaps with 50 MB on the file server. That might just take all the bandwidth on the cable to the server, and also I assume that the network card might be choking for a couple of ms. 3) Right, a directory copy is the way to go. However, you must install the service first, so that the PBX automatically starts up in the beginning. I would just make a fresh installation on the new server, verify that it starts the PBX after a reboot, and then copy the working directory over. If your license is MAC-based (MAC address, not MAC computer ) you might have to call the sales team and ask them to issue a new license key. Ideally you have used DNS in you installation, so that you dont have to change IP addresses .

Thanks for the update. The motto "what I dont understand cant be allowed" seems to prevail on firewalls...

For that you need to install another tool which you find on http://www.wireshark.org/.

No, just assign the MSN to the extensions. Then the name of the extensions are "40 398330" and "41 398331" and "42 398332", for example. You can also assign multiple MSN to one account, for example "40 398330 398331". A extension or account number is treated by the system pretty much like a MSN.

The SIP log looks okay, nothing unusual. Your PBX is obviously on a private IP address, did you use port forwarding on the router? Maybe the RTP ports are missing. If it all does not help, consider making a Wireshark trace; then we can see what exactly is going on with RTP.

Whow.

The easiest is to assign alias names to the extension names, e.g. "40 030398330", which means that the extension has the (primary) name 40 and the name 030398330. If you have set the country code in the domain to 49 and the area code to 30, then the number will autoamtically be translated into +4930398330.

I also would not worry about the address book; that can be solved using LDAP (is already standard PnP). I guess the company will have more than one phone number.Good gateways have the ability to route inbound calls depending on the called number, so that it would be no problem to send the inbound calls to the right destination. If you can partition the user base into domains (departments) that have less than lets say 100 calls, with a relatively simple setup where you dont even need a SIP proxy.

We have installations with 1500 extensions on one system, however the call intensity is low. Usually customers split larger installation base up into several domains and servers. This reduces the CPU load, so that per server the call volume does not exceed e.g. 150 calls. You can also use multiple core devices and then use the virtualization mechanisms to split it up into several VM. This also allowes you to implement hardware failover while keeping calls up. My recommendation would be: - Use virtualization on a system that does not host any other virtualization services (CPUs exclusive to the PBX service) - Everything in the same VPN or even LAN, so that routing from one PBX to another does not create NAT problems. Then you can use a relatively simple dial plan and gateway trunks between the PBX, without the need to run a SIP proxy. - The extension plan above makes a lot of sense. One big question is how to partition your user base into domains. The domains will be the base for you later physical setup. For example, which auto attendants should the system have; which ACD groups and who should be allowed to pick up calls from each other. - You also need to think about PSTN breakout. Outbound calls should be relatively easy; however it would be important to have a concept for inbound calls. For example, if you have busy ACD groups with seperated DID, it makes a lot of sense to put them on seperate PSTN gateways or SIP service providers. This should not be your first installation; you should have someone who knows the PBX well, so that you don't run into problems down the installation path. The fact that you used sipp is a good sign, it seems that you know what you are doing.

Is this really related to voicemail? What if you use other services, e.g. call the auto attendant? It sounds to me like a problem more related to the phone. For example, one phone could be in the LAN, the other one in the WAN.

Well one last chance would be to put the device into a 10.4.50.x subnet and try to access it from there. If that does not work, the device is a case for the JTAG tool (repair).

As for the phone firmware, I would move to something like 8.7.3.10. The 8.4.18 version is already quite outdated and zillions of bugs have been fixed in the meantime.

If you have no voice, the problem is probably related to NAT. If would be good to know what service provider you are using; then we can give you some tips what could do the trick.

You can try to use the IPv6 link local address, see for example http://snom-m9.blogspot.com/2012/02/whats-link-local-url.html for what that is. For example, you can use the link <a href="http:///a[fe80::204:13ff:fexx:xxxx]x">http://[fe80::204:13ff:fexx:xxxx] where the xxxxxx are the last 6 digits from the MAC address.

There were a lot of problems with log files cluttering the file system. Is the file system full? If yes, check if the NetBorderExpress is filling up the file system. In Linux, you can use du and df to find out if the file systems still have space and where the space is used.

Dropouts over cable modem can have many reasons. We even had cases when the audio got choppy at 3 PM when all the kids in the area came back home and started playing online games--which overloaded the carrier backbone. Make sure you dont screw your system up because of factors that are outside. This is a great opportunity to backup your working directory of the PBX, so that later you can always restore the current state. The PBX at least tries to keep track of the audio quality in those images that you can see on the status screen, and also on extensions and trunks. 4.1 is what you get in an ideal case (using G.711 codec). If you have numbers far below that, then the PBX is aware about the problem--which is in turn a clear indication that something is wrong with the network traffic. -18 % does not sound healty. Maybe you can quickly check from the operating system if everything is okay. While you are on it, maybe you can also run the defragmentation tool to make sure we are not getting into a swapping issue here. A common pitfall (time bomb) for memory is that the PBX accumulates lots of CDR in the cdr* directories; this can eventually cause a lof of memory usage. If you dont need the CDR, you can just move the directories out of the way and restart the system. Make sure that you change the CDR duration in the system settings of the PBX, so that you dont run into the same problem again. If all phones are affected, I guess we can forget about rebooting them.

Why not version 4.5? A lot of bugs have been fixed since 4.2. Well, this is all about a proper routing table on the operating system. Most services run only on TCP where the routing table for server sockets is not so important. But for TFTP and RTP the routing table must be 100 % clean. The PBX must be able to open a UDP port, connect it to an IP address and then use the right IP source address when sending a UDP packet from that UDP port. My recommendation is to just put the IP address of the PBX in there; by default the phones should use TFTP protocol. Version 8.4.32 is already somewhat outdated; seems like 8.4.35 is available for all devices. Though I did not verify that the 8.4.35 fixes the problems with the Option 66 URL; otherwise 8.7.3.10 might be your next best shot. If you take a phone out of the box with 7.30, it should be able to automatically update to the 8.4.35 or 8.7.3.10 version without touching anything then.

Can you check if the memory on the phone is stable? On the web interface of the phone there are some stats, and if you can check e.g. every 10 minutes it should be clear if the problem comes from that area.

I dont think this is related to the service provider. The B2BUA in snom ONE makes sure that such problems are shielded. Extremly loud white noise is usually a sign for SRTP problems; however the checksum check for SRTP should make sure that the packet is not being played back at all. Some very old versions ignored the checksum, but the version of the last years suppress packets with wrong SRTP material. The beeps before the dial tone are "interesting" and might help to point to the problem. The dial tone does no come from the PBX, it is generated locally on the phone. If the phone gets erratic, then it is very understandable that also other artefacts like white noise might happen. Here it would be interesting to know what firmware this is and if a firmware upgrade makes any difference.

Ouch. Sounds like something that needs to be fixed immediately.

You need to register the SPA to the PBX as extension. If you have FXS that is extension on the PBX, while FXO is typically a gateway trunk. Once you registered, you should be in good shape regarding basic features. After that you have to check what codes are set up on the SPA, so that you can e.g. call Do Not Disturb from the FXS.

If there is trouble with the actication please send an private message to me with the activation code and the MAC address(es) of the host. We'll then provide you with the license key manually.

Okay, that means we can forget about problems with transfer buttons and star codes etc. What would explain it would be a SIP INVITE from the gateway that has the same call-ID like another previous call. Then the PBX would take this essentially as call pickup and connect the two calls. While this is a wild theory, it somehow does narrow down the problem to the gateway side. The good news is here that the traffic should be unencrypted, which makes it possible to run Wireshark andrecord only the traffic between the gateway and the PBX. I did not find any information about DLINK 100MO, but if that is a managed switch, you can probably do a port mirror of the PBX or gateway port and record the traffic on a PC "non intrusive". Then if we have the time and a number, we can easily go to the right trace and hopefully solve the riddle. If the patton is in the LAN and the two accidentially connected parties are talking both through the same gateway, we can exclude firewall and sip service provider problems.

The PAP2T would have to access something like http://pbx/prov/pap.cfg (notice the prov in the path, which can also be provisioning). This is neccessary to tell the web server that this is a provisioning file. If you can do that, then you can also use the internal web server of the PBX and access the files in the tftp directory (prov in the URL uses the tftp directory). Simple question, complex answer. You need to tweak the configuration options so that things work the way they should. For example, the default "dial plan" on the PAP2 has star codes that interfere with the codes from the PBX. If you dont change them, your users cannot use features like DND or call transfer. Right, provisioning points to the tftp directory. You can try this from a web browser, that is easier than trying it out from the device itself.

Since version 4.5, you can put whatever you like into the Remote-Party-ID header, e.g. just something like <sip:nice-day@voice.heliatool.com;user=phone>. http://wiki.snomone.com/index.php?title=Trunk_Custom_Headers has a list of available macros, but you can also just put text there without macros.