Vodia PBX

Does the ACD connect the call (meaning: does the caller have to pay for the call)? There is a option that tells the PBX to connect the call only when the agent picks the call up; but for a busy group that is usually way too long. What is the event for connecting the call? If the handset is ringing for so long you should redirect the call out of the queue, for example into a hunt group. It is just not good to keep the handset ringing for so long. You might even redirect the call back into the same ACD; customer will not be amused to get kicked back into the queue (especially at the beginning of the queue!!!) - but this is still better than a dropped call.

You don't have to reboot to change this setting. See http://wiki.pbxnsip.com/index.php/Global_Settings on how to do this on the life system.

We are working on a solution that transcodes inband into RFC4733 DTMF. In theory it is working, but in the real life we still have problems. Stay tuned, we want to include this into the 3.3.2 build.

There was a report about instable USB, which was even causing jitter every couple of seconds. A defective dongle, I doubt that. I believe that the regular polling of the dongle causes the driver to go crazy. We slowed the polling down significantly, but it seems the problem is still there. What OS is that? If the problem persists, ask for a MAC-based key instead (even if it expires after some time). That should help you to stabilize it until the root has been found.

Well, the PBX tells the phone to "auto answer". So it is not a problem with the number of registrations. This works only if the Polycom was automatically provisioned by the PBX, as the default config does not support the intercom mode.

Is there enough bandwidth between the PBX and the phone? If the phone runs the conference, keep in mind that there are two calls between the PBX and the phone. If you are using handsfree mode, you might want to check out the latest conference phone (snom meetingspoint).

We are starting to make builds for version 4, but it is far from being a release candidate yet.

Well, the PBX does not suppotr NTLM authentication. I guess you need to change the Exchange setup so that the regular authentication is accepted. Or maybe you can just whitelist the IP address of the PBX and skip the whole authentication part.

You can put a one-person hunt group in from of the AA (the only person in that hunt group would be the secretary). However you will obviously loose the FAX functionality, unless the secretary wants to detect the tones and redirect the call to the FAX...

Regarding the DND button there will be a fix coming out in 3.3.2. That area was not very clean and should be better now.

Maybe send me a PM with the provisioning info and we'll give it a try from here. If you have Remote Desktop or at least a HTTP login we could even try to get it working. Seems this is a problem of the test environment.

Maybe just turn TLS off. In the email settings there is a flag called "Enable TLS", try turning it off.

Oh the AA does not use regular expressions. Just put a "F" into a "User Input" and then the FAX extension into the "Destination". The AA will detect the FAX tone similar to a DTMF tone with the name "F" and will behave as if the user entered "F" during the annoucement.

This should be a certificate problem. IF you get one, make sure that you use a 1024-bit certificate. I remember there was an issue using more than 1024 bits.

Aha. Dit not try it... But I believe it should be simple.

Do you mean ENUM??? http://wiki.pbxnsip.com/index.php/ENUM

The XML looks fine. The question remains if the phone loads it (or tries to), you can see that in the log of the phone. If not, you might have to move to a newer version - not sure where the additional custom file was introduced.

You can make the ANI depend on the trunk. For example, "Trunk1:9787462777 9781234567" would mean: When using Trunk1, then use the ANI 9787462777; else use 9781234567. If you want to use that, trunk names must not have a space. Maybe that is the way to get this working.

There are different layers here... The PnP parameters are for decisions that the admin has to take when using the standard PnP procedure. The custom file is for those "millions" of settings that usually not neccessary; this is just to provide more flexibility. Most admin would never use the custom files.

Oh, sorry misunderstanding. For that, I would suggest two extensions on the same phone. Many SIP phones allow you to have multiple registrations. This would solve the ANI problem. However, it comes at the price of increased complexity for the user when picking up calls & Co. There is always a trade-off.

Hmm. That simply was not envisioned... Sending a call from the dial plan to an extension was really only for an extension. We may provide you a build that also allows calling other accounts like extensions.

It was already possible to assign a MAC address to multiple extensions. Then the PBX would provision multiple identities to one phone. Version 3.3 introduced a new feature. You may now also list multiple MAC addresses for one extension (seperated by a space). This makes sense e.g. if you have a cordless device and a desktop device on the same extension. Usually it is a better idea to solve multiple ringing with a hunt group or an agent group. Having multiple extensions on the same PBX on one phone usually just screws outbound calls from that phone up. You never know what number is calling, and especially for call pickup and call parking things get very messy.

We have added an additional header called "Related-Call-ID" that makes it possible for the service provider to verify that we are not spoofing the Caller-ID and the outbound call "relates" to another inbound call. AFAIK callcentric.com has already happily implemented this and their customers can enjoy a proper and safe cell phone redirect.

If you set the country code and the area code, the PBX will try to present the number in a "human readable" format. Be a little bit careful with this feature (backup before doing it), as changing the country code triggers a table scan for the address book and internally reformat the address book entries as well.

At the moment is it a little bit "foggy" if we should treat such cell phone calls as trunk calls or as extension calls. So far those calls were trunk calls (like a stupid redirect), but it seems more and more than trunk calls must be also be extension calls. As we are cleaning this area up in version 4, that will be a lot cleaner.