UC320 first impressions - questions

[bjames]

So I wound up with two UC320 test system for review, and I thought I would put my impressions, questions, RFE's here to see what's what.

Nice design, gets a little hot, and I hope it's not just a rebranded SPA9000

I was surprised at no CCA support as I have a ESW 5230 switch with the kit which I had to configure separately (Unless you go will all the Cisco defaults), so I had to configure both devices separately.

Time, it's off on the phones and there is no place (I can see) to change it on the GUI. I assume it's using NTP out the WAN port, but because our NTP is restricted at the firewall level between certain hosts only, it is not getting NTP.

WAN Port, although the documentation says to use a secure router infront of the UC320, some of the diagrams show it directly connected to the Internet, and having port forwarding can make people think the UC320 is a firewall.

Phones; no way to control the phone pages (GUI) or upload code to them. I was able to get right into the admin page of all the phones, and I think this should be password protected from the UC320 GUI. I have newer code for a SPA303 but I can't figure out how I can upload it to the phone or UC320 to load to the phone.

Flash; it uses it so I cannot control it from an iPad (I can ask can't I)

No backlight on the 303 phone, really? I know it's a bargain basement phone, but there is a shadow cast from the top bezel that makes the display hard to read; how much does an LED cost anyway?

Applying any configuration change reboots everything - Really annoying and hard to justify this with the clients "Yes I can add a new user, but it will take out all the other users while the system reboots"

Is there no way to set presidence on the individual phone lines (FXO)?

Inbound calling; confusing, if I set an inbound number to go to a certain extension it looks like my only option is to tie it to one line (FXO), what happens if I have the lines roll over when busy to the next line? I'm confused

911 again confused on this, if I set 9 to dial immediately it looks like it's expecting a 10 digit extension, I use 8 for an outside line, but I still want to be able to dial 911, how do I set the line, dial immediately or outside line?

WAN interface - This surprised me, if it goes down the whole system reboots when it comes backup; what the heck is up with that???

This is all I have for now as I haven't had too much time to play with it. But do upgrade your ESW switch code as I know this was the cause of some issues.

One last question; is one of the FXO ports a passthrough (voltage) to and FXS line? In an emergency it's nice to have a good old analog phone with line voltage that still works, so if it doesn't might be a good enhancement.

Bob James

[blaw]

Hi  Bob,

Thank you for reviewing the UC320. We will love to answer any questions that you might have.

Some of your questions are easier to answer by first explaining the design philosophy of the UC320. The system targets small business office with 25 or less users. We want to keep the system installation simple while appropriately flexible. This will minimize the staff training cost for our partners and thus more profits for them. Here is a few design decisions result form that:

1.       There is no separate installation of a configuration utility such as CCA. Everything you need to configure the UC320 and the phones are through one single embedded GUI in the UC320. All you need is a browser. Sorry you do need flash, so no iPad .

2.       The phone firmware is always bundled with the UC320 firmware. Furthermore, phone firmware is automatically downloaded by the UC320 transparent to the installer. This keeps installation, testing, and support simple.

3.       The CDP capable ESW is plug and play when working with UC320. Thus the UC320 GUI does not do any extra configuration with the ESW. Customization will be done through the ESW GUI itself. But the default already supports both voice and data and adequate for most deployment scenario.

4.       Time is automatically set through NTP which points to a Cisco NTP server. This eliminates the need to configure the system clock or NTP. We have not yet run into a small business office that cannot pass NTP through their firewall. But we have the ability to redirect the NTP to a different or perhaps internal NTP server if firewall is an issue. This is done through a feature extension mechanism call PMF.

5.       FXO precedence is hardwired from FXO1 to FXO4 for simplicity. The practice is plugging in the phones line in the desire precedence order at installation time.

A couple known issues that we plan to address:

1.       Currently WAN interface IP address change (e.g. unplugging the WAN interface) can cause voice module to reload. The fix requires substantial code change while it is either easy to workaround or not an issue for real life deployment. So we have prioritized the more important bug fixes over it for the last release. This is something we will fix in a later release.

2.       We do not have a good incremental editor for the configuration at the moment. Thus minor configuration change will require reboot. This is something we will improve over time. Our partners typically stage the system by pre-configuring it before visiting the customer. For FXO system, one best practice is temporarily plugging the main FXO line to a wireless analog phone while the system is rebooting. This way the customer will not miss incoming calls during the few minutes to do the reboot. But once again, this is an area we want to improve.

Answers some of your remaining questions:

1.       The WAN port can connect directly to the internet or behind a NAT device. Port forwarding is supported.

2.       FXS is set to pass through FXO1 in case of power failure. That is by design though I have not tried it personally in the lab. I encourage you check it out.

3.       You can route multiple FXO lines (e.g. 2 lines on the same rotary group) to the same extension or more popularly to one hunt group. Is it what you try to do?

4.       To dial“911” in PBX mode, you will first dial an access code (typically 8 or 9) to seize the outside line. For example, I will dial 9-911 from my office phone in Cisco (and AFAIK this is how it typically done with all PBX). The same way works for UC320 in PBX mode.

5.       The “Immediate Dialing” is an unrelated concept to 911 or outside line. It simply tells the system to immediate transmit the single digit. That single digit could be assigned to Auto Attendant (by default 0 is assigned to it) or a real person’s desk phone (it should work for hunt group too). For example we can program the receptionist’s phone to ring when anyone press 0 and the boss’s desk to ring when press 9. I will be happy to show you with an example configuration if there is interest.

Once again thank you for playing and evaluating the UC320. I hope my reply has answered most of your initial set of questions. It looks like you have figured out a good part of the interface with little help or sample configuration. Please let us know if you have any other questions.

Regards,

Bassanio

[bjames]

OK,

Just to be clear unless you want to go with all factory settings, you do need to configure your ESW switches and UC320 separately, hence the request for CCA.

I'm surprised you think the WAN port issue is minor, seems like a huge bug to me, does it do this only if the interface drops or does it do it when the DHCP is renewed?

The inbound dialing thing for me still seems strange is there better docs for this; all I want to do is if someone calls a specific number on any line or SIP trunk I want to direct that to a specific local, for all other inbound call send to aa

And on your point 2 on the always reboot after a change, what if the customer is the one doing the changes, the phone system should never have to have a reboot if you are just making simple changes, please put this on my RFE list.

Thanks,

Bob James

[blaw]

Hi Bob,

Regarding the WAN, the problem is when UC320 connected to the internet directly and the ISP changes the address. We orignally thought this is a high priority bug during market trial. But we quickly learn from our partners that UC320 typically deployed behind a NAT device which will provide a stable IP address. For deployment that connect UC320W directly to the internet, the partners themselves want a static IP address for ease of remote management. Thus the workaround (having static IP address) is a best practice for them. But at any rate, we will fix this soon.

Each FXO line can be directed for incoming seperately. There are four seperate FXO ports for each PSTN line. The UC320W can route the call to different entity (e.g. a person's deskphone; a huntgroup; or AA) base on the incoming FXO port. I have attached a picture showing the first 3 FXO lines are routed to a hunt group. The fourth and last FXO line will go to AA.

For SIP trunk, incoming call can be routed based on the DID number. For example one trunk of 8 numbers can be routed 8 differnet ways. One obvious applicaiton is giving each employee their own DID number that ring only their specific deskphone.

I definitely agree minor changes should not reboot the system. I worked with a couple end cusotmers who make changes. They are doing that after business hours. Not ideal but did not bother them as long as the GUI is intuitive. But we plan to make frequent user tasks not requiring reboot soon.

Thanks for the feedback!

Regards,

Bassanio

[bjames]

Thanks Bassanio

It's a quirky configuration, but I will assume with everyone's input here that Cisco will continue to make valid changes to the system and fix the deficiencies.

A couple of my requests for enhancements;

- VPN - both for remote management, teleworkers (525) and AnyConnect.

- Comfort Noise Generation, I can handle the "dead air" but I know a lot of people can't

- Multi-site config

- IP Communicator and CUVA support

- Webex integration

- Better ways to manage both the product(s) and the phones for firmware loads, etc.

This is all I can think of now.

Cheers,

Bob James