Vodia PBX

Well those templates are moving targets. But no secret. So feel free to take today's snapshot! snom_3xx.zip

Again very strange. Can you SSH in and run top?

Did you select HTTP in the server menu of the phone? It should not generate a TFTP link at all...

Oh that is the call volume. This is for adjusting the gain. This does cost a lot of CPU horsepower, you better turn this off if you don't need it. It is in the Log section of the admin mode.

For remote devices, you usually have to use HTTP because TFTP is not a very NAT-friendly protocol. See http://wiki.pbxnsip.com/index.php/Polycom#...ng_Provisioning on how to do that.

Send an email to support@pbxnsip.com...

Upgrade to 3.2... It could be that you are dealing with a problem of version 3.1 - see http://wiki.pbxnsip.com/index.php/Release_Notes_3.2.

Well, the reason could be that the system is not supposed to signal that the other side is actually ringing. Or something simple like the log level is set to 7 and the PBX would not show a message on log level 8. I assume the file is in the file system. Corrupy file systems are pretty low probability these days. It could be really something that the phone is really not ringing or that the PBX does not know about it. A Wireshark trace from the PBX server will show this.

Automatic log off sounds interesting to me. There are already ways to send the call to another location, including the same ACD. That might be a temporary workaround. Especially if is practically only one agent in that queue, so logging that one out really puts us into trouble. The problem that we are more and more dealing with are groups with very little staff. Very! So very that the customer chance to meet a real person is so low that we need to think about ways to pretend there is a real person. It is a challenge. Unfortunately, if you fire the last agent that will not make the customer more happy...

I am not an OCS expert, but that sounds like you need to tell OCS how to find the destination.

Hmm. Are you on version 3.2?

No. That should not be the problem... Do you automatically provision the phones? What is your password policy for provisioning (See Admin/Ports/TFTP). Maybe your phones don't get the password after the first provisioning. What phones are you using?

Try to set the country code in the domain to "31". On the trunk you can set how the trunk should represent numbers to the outside world, e.g. with plus or 00 at the beginning. Make sure you are running 3.2, I think that option was just recently added.

I would move to 3.2 anyway.

Hmm. So that means that there are call that just hang and don't get out of the system (maybe after two hours or so)?

If you cannot ping the system anymore we are talking about a problem at the lower levels. Maybe you can log in through SSH right after startup and then start top to see if we have a problem with the memory, CPU or something else looking strange. Anything else strange? If the network in good shape?

You can still perform a TFTP software update of the phone through the bootloader. That should also reset all configuration, including the one that is causing the problem.

That is not good. It means that those CO-lines are not properly associated with a trunk I guess. Could be from older versions, or they could be lingering from an unsuccessful attempt to create them. Anyway, this log has nothing to do with the number of CO-lines that you can have on a trunk.

Is there any chance to set up another system for testing (3-minute key) and see if the version 3.2 solves the problem? Then in a seconds step we can see what we make out of this. Unfortunately, the CDR logic inversion 3 is quiet different from the logic in version 2, so this will not be an easy patch.

It could be a problem with the routing table. It is not uncommon that the OS chooses a different route when you add a second IP address. Sometimes the NIC with the private IP address has a higher bandwidth and the OS thinks it is wise to send all traffic through the NIC with the higher bandwidth. What is the output of the "route" command from the command line? See http://wiki.pbxnsip.com/index.php/One-way_Audio.

There is no limitation built-in. 23 Should be no big deal.

Looks like you need Wireshark to see what is going on.

Some trunks cannot deal with early media. Check if you have the flag "Ringback" set to "Message 180". You can easily see if the PBX sends media by using Wireshark. That should further help to nail the problem.

Just updated http://wiki.pbxnsip.com/index.php/One-way_Audio.

Try changing the "13" to "12". Maybe that was the problem.