First Install Feedback and Issues

[Barry Jeung]

Completed my first install on 9/1. Replaced a customers key system and attempted to emulate the old system with shared FXO lines. The customer has 3 FXO via Comcast.

Initial install was very easy and straightforward. User interface pretty self-explanatory. System was up and running in about 45 minutes, including replacing the customers existing firewall and connecting all the extensions.

Problems/concerns I noticed initially:

- Shared FXO line labels on the phone were incorrect. The system was using the alternate label from the 'Line (FXO) Trunk' configuration instead of the label from the label from the 'Shared FXO Line' section. In otherwords I had put the phone numbers in the alternate label configuration of the trunk, and put 'Line 1', 'Line 2', 'Line 3' in the 'Shared FXO Line' section. The phone numbers were showing on the phone buttons.

- Couldn't change the Shared FXO line button order on the phones. Line order is determined by the order the phones are added as members to the Shared FXO line configuration. So to change the order you have to remove the phones as members from ALL of the shared FXO lines and then add them as members in the order you want the buttons to appear on the phone.

- Delay in answering the phones, most likely due to the caller-id detection. When a call comes into the system on the shared FXO lines, the buttons on the phone blink red for the first two rings, and the users try to pickup the call but they can't. Once the CID info is passed, the line will turn green and the phone will ring audibly. The system should either not show the incoming call until the CID info is passed or let the users answer the call immediately without CID information. Would be nice if this was configurable, but if I had to have it one way or the other, I would prefer the system not show the call until CID information is passed.

- Customers without the color screen (SPA525) immediately complained of glare on the LCD displays. The was a common complaint from all the users with the grayscale LCD. Either a different screen material, or a insert/cover of some sort, or an adjustable stand is needed to correct this issue.

Problems/concerns since the install as reported by the customer:

- Have a problem with a line remaining 'in-use' or seized after a phone call. All phone show the line as being 'in-use' when there is no-one on the phone. Calls that come in on that line (shared FXO) go straight to the AA. Users are unable to pickup the call. The line does become free after sometime (unknown length of time) but the customer has had to reboot the system due to occassions where all three lines were showing as 'in-use'. Customer has noticed that it seems to primarily happen when one particular user makes calls, and if the line button is pressed from another phone, it shows that the system believes the call is still 'in-progress' and will show the CID info from the last call made on that line.

- Long digit timeout when placing outbound calls. Configurable digit timeout and configurable dial plan is needed.

- Inability to pickup calls in-progress. With the old key system, the customer used to be able to pickup or 'barge-in' a call in-progress simply by pressing the line key from another extension. They are unable to do this now.

- Random reboots. After some discussion with Navin, this appears to be a known bug and is being addressed. This is unrelated to the WAN reset issue.

[Barry Jeung]

Some additional concerns reported by the customer that I forgot in my first post:

- Customer comes from a key system and does not want to dial 9. I can disable this in other systems I've worked with (Asterisk) but this is not configurable. As a work around I instruct them to press the shared FXO line button first, which allows them to dial out without a 9. Basically the key system emulation is backwords in this system. In a normal key system, the user pick's up the phone and can dial out, and if they want to dial an internal extension they either press a configured button (like a BLF/speed dial) or they press 'intercom' and then the internal extension. Here, when you pickup the handset, it's defaulting to 'internal' dialing.

- Unable to change the first button on the phone. This relates to the problem above. As a work around, if I could change the first phone on the phone from the default of an extension to a shared FXO line button, then I could better emulate their key system. Or if I could change the behaviour of picking up the phone do default to the shared FXO instead of the extension, that would work also. I imagine changing the behaviour might be a better way to do it, as I imagine this would be a problem also for phones with DID's that would want the ability to dial out from both their DID and the primary number on the system, although I haven't tried this yet.

- Customer was able to pickup calls with the old key system at any point, even if the call was in VM. So if someone dialed an extension from the AA, they could press the line button on their phone to grab that call, even if the caller was leaving a VM at that extension. They miss the ability. Grabbing the line while the call is in-progress is a standard key system feature. Grabbing it while in VM, might not be, but their system could do it.

Basically, from what I can see, the key system emulation is poor. This is a common problem among PBX's that try to emulate key systems from what I can tell, not just the UC320. I would say the best bet is to have an entirely different FW for the UC320, so you have different paths, or drop key system emulation entirely, which would leave more flash mem for PBX features. No key system emulation is better than poor key system emulation.

[Barry Jeung]

One more that slipped my mind.

- Call waiting tone should be configurable. The customer wants call waiting, but doesn't want the beep in the ear. The flashing button is sufficient for this purpose.