I have an issue I am trying to track down the cause. The hardware was installed as recently as two weeks ago. Over the last few days the inbound calls to the system and outbound calls from the system stops working all of a sudden. The unit shows flashing LEDs on FXO line 1 and line 2 and also voicemail. When the system is rebooted, the problem is temporarily resolved until the next time. From what I have been told, the phones do not lose their registration. I also believe that the phones are able to dial internal extensions during this time. Any ideas what the problem might be.
Maybe someone else might have the right answer. But I do have a question. I'm assuming the 320 dials over the FXO ports and that there is no SIP trunking going on.
How is inbound call routing setup?
Is both POTS lines from the same provider?
Do they share the same inbound DID?
Can you reproduce the problem by calling from 3 outbound calls? Or 3 inbound calls? (3 because you only have 2 lines. From the sound of it.)
Next time instead of rebooting the UC, remove both POTS lines. See if the flashing LEDs stop, does the problem go away? My hunch is it's a call rounting problem. Sorry I don't have the answer.
The system is set up in PBX mode. There are two FXO lines and all are grouped for usage. Inbound calls go to the auto attendant (no day/night schedule). POTS lines are from the same provider. Each line has its own direct number.
Did not try dialing out with 3 lines?
If it is a call routing issue, would that manifest itself all the time when handling just one or two calls? Can you tell me what about routing would cause an issue like this?
I'm just thinking outside the box here, again I don't have an answer. But thinking if a internal dialed number just keeps forwarding between two numbers. Tieing up both lines.
Again try removing one line or both lines next time you have the problem. Sounds like a non-repeatable problem.
We are having a similar problem this occured when we installed firmware 2.2 and the auto attendant will not pick up. Our system setup is almost identical to yours with the exception we have 4 FXO lines that are all grouped for usage. When I reboot the system it accepts the calls and starts working. I am at an inpass as to why this is needing to be reset.
Any help would be greatly appreciated.
We have had this issue as well (among many others) in PBX or hybrid mode. Due to the issues, we moved the small system to Key mode. Currently the system (in KEY mode) with (2) CO lines and (3) stations needs to be rebooted (soft reboot) at least once a week, or very odd things start to happen with call routing. Currently, if a caller is using CO1 and a call comes in on CO2, it RINGS into the handpiece of the person using CO1.
Sometimes calls stop appearing on the line buttons and have to be answered using the extension buttons, as odd as that sounds.
If there is a power outage, the system comes back up with the AA enabled (customer DOES NOT use AA) and calls are NOT routed properly until the AA is turned on then off in the GUI and a soft reboot done. A hard reboot always enables the AA and the procedure needs to be repeated.
The situation is almost comical, if not utterly sad. This has to be, hands down, the worst piece of equipment that I have ever worked with and a year of updates have not improved anything.
I have been working with Cisco to fix this exact problem. I think they fixed it with the limited release firmware, but that "fix" opened a whole can of worms of other issues. I'm currently waiting on a callback from L2 to continue working on the issue, and I'll make sure to post here if we do find a resolution.
Thanks for this info. Please keep me updated. As for "other issues" can you give me a sense of what that is. I figure if those don't apply to me and I need the fix, it still might be a viable route to use the limited firmware..
So far we have identified a problem with the AA not working that affects the SPA8800 addon-unit, and on the UC320W calls that route to reception directly (no AA turned on) have to be answered on the second ring. If they are answered on the first ring, both ends get dead air. The good news is it hasn't locked up completely in over two weeks.
It looks like the issues have been fixed with a minor change to the config of the UC320W and the limited release firmware. Cisco L2 had me change the voice subnet to 192.168.x.y (where x and x+1 are not already in use on the network). Apparently there is an internal IP in use that can sometimes get conflicted with the default voice subnet, but if you change the voice subnet to a 192.168.x.y, it will automatically set the internal use IP to a subnet of 192.168.x+1.z.
Long explanation, but it seems to be working so far.