Vodia PBX

That log looks fine... The license problem is also okay (just no RTCP-XR reports). I don't think downgrading will solve the problem. Maybe send me a private message with a login (HTTP and SSH preferred) and we can take a look from here.

It is still not clear to me what the setup is. Maybe you can include a little drawing. No big art, just something scribbled on paper and scan it... Maybe the problem is that this is not a trunk call? ANI has no effect on calls that are to extensions.

Hmm. Do you see the generated files in the PBX "generated" directory? Do they make sense (e.g. do you see the account info in the polycom_phone file)? Can you format the phone's file system and reset the local settings? Sometimes that helps, though it does take a lot of patience to go through all these updates.

The INVITE from the phone's log (the one that receives the INVITE) would be interesting!

If you can, avoid virtual machines. They might end up in resource conflicts and yes then it is not clear who gets the CPU. Though I heared there is some progress on VM. I would use it in a test setup, but I don't feel safe in a deployment yet.

Looks like you are using the wrong boot rom? Should be something starting with 4. Also, if you are using the phone from a remote location, make sure that you are using HTTP. TFTP is not very NAT-friendly!

If the phone is ringing for so long it becomes a major problem. Most phones don't ring so long and they send a response back that looks like the user rejected the call. I would suggest to escalate the call after 90 seconds into another queue or even to a hunt group or a cell phone. Eventually someone has to pick up the phone!

Does the agent's phone ring for 2-3 minutes? Or do callers drop out while they are in the queue?

Remote-Party-ID is a old, obsolete Cisco proposal for indicating the remote party. It expired a couple of years ago. Everyone in this industry should better stop using it. We are too nice and we still offer it. I believe even Cisco does not offer it any more in the latest versions. P-Asserted-Identity and P-Preferred-Identity made it to the RFC state. This is the way to go. AudioCodes as one of the better products in this industry fully supports it. Regarding the cell phone redirection, there is the old problem: How can the gateway "trust" the PBX that this is not a spoofed caller-ID? Especially for ITSP that is a huge problem. Because of this, we introduced a new header called "Related-Call-ID" that indicates the original caller-ID. Not RFC yet, but at least CallCentric said they are going to support it and then the original caller-ID will show up on the cell phone. Bravo!

That algorithm does not work properly. For example, there are people in this world that have the same cell phone number like their home phone (e.g. +49-171-8028055 and +49-30-8028055). If you are in USA, use the country code "1". That will tell the PBX that the caller-ID can be 10 or 11 digits and it will automatically concert it into a global format. If there is no country code the PBX will not change the numbers and use them literally. Then it is very likely you are running into problems with the matching. Also on the trunk, you can tell the PBX how the gateway or service provider wants it. Then also for incoming calls, it will convert the number into the right global format. Make a backup before you change the country code. The code changes a lot, also changes the address book entries. If something goes wrong, you want to be able to revert to the previous state.

I would factory-reset the phone and provision it automatically. There is no need to change the configuration; the PBX will signal the intercom feature in the INVITE.

Hard to say what the problem is. Only a trace would tell. But 3.3 also has a new feature that locks the codec, that usually helps to sort this kind of problems out.

One key might be that you can register the branch office to the main office; then assign all DID numbers to the ANI field in the registered extension (seperated by space). Then when the branch office places a call, the PBX would pick the matching ANI for the outbound call. For inbound, you can assign the DID numbers as alias names in the extension in the main office.

If you have CO-lines on a trunk and the PBX would like to use this trunk for an inbound or outbound calls, but all CO-lines are already busy and the call has been rejected.

As long as you are able to split the user group up into domains with 75 calls per domain then you can do that today. You need to run several processes; each one bound to a seperate core (leave one core for the OS). Each process has a different working directory. And you either bind each process to another IP address or you use different ports. In Linux/BSD this is relatively straightforward. In Windows, you cannot use the standard installation procedure but must use another mechanism to set the services up. In any case, the key is to be able to split users up into smaller pieces. Then you can scale along cores and servers.

What are the chances for an upgrade? Maybe the problem is already "automatically" fixed in a newer version.

I remember Bill H recommended to use an analog measurement tool to se what is going on. There is also other gear available that amplifies the signal.

I you require that users have to enter their PIN code when going to their mailbox, then they also need to punch in their PIN code when they want to record a call. Then they must have a PIN code - no PIN code, no recording.

Consider moving to a 3.3 build; there were cases when the speed of the file system caused problems with the mailbox message.

I would not use STUN. It works in many cases, but not in all cases. STUN is extremly support intensive; there are so many routers out there that have different implementations of NAT. Some of them work "most of the time", then when your customer calls you you spend hours on the phone trying to figure out what the problem is. Also, running the PBX on a not-routable IP address creates a lot of grief if you want to register phones to that address. Yes, there are "tricks" to get this working as well (described in that Wiki page). My bottom line is: If you want to connect remote users, get over it and get a public IP address. Fortunately, most service providers understand that trunks mostly come from private IP addresses and they offer some kind of SBC service. So if you register a trunk to a service provider, you usally don't need a public IP address. I assume here that the service provider has a routable IP address! On day when IPv6 is out, we'll all laugh about these problems.

We are using PRTG. Setting up the OID did not require a MIB. Pretty straightforward; though the version is already a couple of years old.

Hmm, interesting. We need to put the whole ring tone topic on the agenda for version 4, including the callbacks (also for camp on).

In analog PSTN lines, the other side play a tone to signal that the call has been disconnected and the subscriber should disconnect the call. More than hundred years ago people were happy when they could hear the other party. Today, we have tones coming from such strange sources like cars (when you open the door). The PBX might believe that this is the disconnect signal! We also had cases where the carrier was playing such useful hints like "your call has been disconnected, please hang up". You need real intelligence in a PBX if you want to deal with that. Proper hang-up detection is really difficult in the analog FXO world of Alexander Graham Bell. We tried to put some intelligence into the FXO trunk on the PBX side (check "trunk requires hangup detection"). If you feel it is too agressive, consider turning it off. However, then callers might hang in the auto attendant until the hangup-timeout kicks in. I love SIP trunking. Reason #1 is a clear disconnect signal.

If you have both a private and a public IP address configured, then you probably have a problem with the default gateway. If you tell the PBX to use a private address as the default gateway, it will send it there and then you will also see the private IP address in the SDP. If you have only a private IP address things will get tricky. Then you should study http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses. If you don't like what you read there get a public IP address...

You should definitevely turn on the email reporting of such events. Then you get an email when a gets dropped by the PBX. Also, you better use version 3.2, 3.1 has a ugly bug in the web interface. What you can do is writing a log file of the SIP traffic (only "other" message types) to the file system. Don't write all the other stuff, it just makes the system drown in messages. In the BYE message, the PBX reports how many packets have been sent and received. If there is something out of balance, then you get a hint. In the 3.3 version we added sending of email messages when the user hangs up during a one-way audio situation. If the problem persists, you might have to (temporaily) move to version 3.3 to get better information. Make a backup so that you can move back to the 3.2 version after the problem has been identified!