I am waiting on the support contract number to come through for this customer but I thought someone here may know the fix already.
I have a UC320W which sees the spa504's ok but the single spa509g just doesnt want to register. I have tried resetting to factory defaults via the handset and I have tried adding it in manually.
On the network settings I can see that it is not picking up the voice vlan 100 IP address range so I tried giving it a static IP on the voice vlan along with the manual settings. I have tried setting the vlan setting to yes and vlan 100 with dhcp enabled but still nothing.
It is running software version 7.1.3, anyone got any ideas?
Is this connecting via a supported switch or with a power pack plugged into it and then in the back of the UC-320W?
If it is through a supported switch, which model is it?
And if it is through a switch, reset it to factory defaults, plug a power pack into it and then plug it directly into the back of the UC-320W, this way the phone becomes provisioned and then it should work through the switch.
I have hit this problem a couple of times now during the staging process before installing at the clients site, and it has only happened on the SF/SG-300 series switches, has not happened yet with the ESW range.
Let us know the setup, it may help with working the issue out.
Also what is the error coming up on the screen, is it stuck on the "initialize the network" message??
It's connecting via a SG200-26P on a PoE port, unfortunately I dont have a power pack to play with right now.
No it doesn't have the initialise network page - it's on a page similar to a successful boot with the time, redial/dir/cfwd/dnd buttons active but no actual line number/extension.
The signalling protocol setting does say SIP and I set SPCP autodetect to No.
I might see if I have any luck with a firmware upgrade of the phone, current release is 7.4.8 and the phone has 7.1.3
Thanks for the idea David.
Try version 7.4.7 V11
That is the version running on our LAB which was just recently updated with the most recent production release (Cloud based update).
Can not offer up any other advice sadly, the issue you just explained is something I have not come across yet.
(PS) I normally use the user import sheet and use a scanner to put in the MAC, but that's just my lazy way of doing things.
Upgraded to 7.4.8 and the SG200-p26 switch to 184.108.40.206 -, factory reset phone - still no joy.
I'll try adding in manually again and see if I have joy.
I wish right now you had a power pack for it, this way we could have removed the switch as being the problem.
Silly question though, have you tried other ports on the switch or just keep trying the same one?
Not sure that this will help since you have 504s that are working, but one goot trap with the 200/300 series switches and the 1.1 firmware upgrade is that if you *upgrade* the switch from 1.0, then the auto voice vlan feature is disabled. This is on the assumption that the pre-existing config should be honoured and we shouldn't go creating new vlans without an explicit say so. This is great when upgrading a switch that is already installed in a network, but not so ideal when the switch shipped from distribution with the 1.0 software and is being upgraded prior to being installed. The problem should disappear soon as the switches running the older firmware get flushed through the system.
Anyway, the long and the short of this is that you should try factory reseting the switch config. Then the voice vlan should be automatically created and all the ports given a smartports role of IP Phone+Desktop. If that still doesn't work, post it here and we can dig further. Or if it is time critical, then call the SBSC and log a case. Either way, we'll get the problem nailed.
Things went from bad to worse last thing on Friday, I put aside the original problem and focused on getting everything else all sorted figuring that might just tap the support centre for their expertise on Monday.
Anyway I added in changes to set inbound calls for specified numbers through to the various extensions that needed DDI's and then found I could nolonger dial 1 for an outside line, "invalid number", (inbound ddi's worked but only can dial extensions) I then tried setting 9 to be the outside line, apply but still "invalid number", tried rebooting phones - no joy, tried resetting a phone to factory defaults....et voila! now I have a spa504 phone showing the same symptom as the original spa509. A wonderful end to the week.
I know you are not going to like what I am about to propose, but it is worth a shot and may save you a lot of headache and time.
Reset the UC-320W back to factory defaults, but before you do this, do the following:
You should be able to rebuild this system in under an hour and a half, with the help of the user import sheet, this will bring it down a bit.
Again I know you are not going to like the suggestion, but in principle if a build process has not gone well during the staging process, I just keep starting from scratch, this way when I get to the clients for deployment I do not end up red faced because it just doesn't want to work, this is a tried and proven method and I assure you it works building on initial bad builds only leads to more problems down the track.
Just a thought...
Thanks again David,
I didn't rebuild it entirely as I found that once I enabled the auto voice provisioning on the SG200 the problems with the handsets completely evaporated. Until you mentioned it I hadn't even through to look for the setting. (I may yet do as you suggest.)
Everything is working correctly now apart from one small (ha) problem - the UC320 is rebooting itself every 7-10 mins. I understand that this is a known bug but I assume there is some WAN checking beyond Layer 1 as it still occurs when I have placed a new switch on the WAN port between it and the ADSL modem. What it is I am not sure as the ADSL connection isn't flapping.
I'll get in a SR520 and see if that helps otherwise I can't wait for v2.1 to be released.
Good to hear you got somewhere with it Daniel
How is the WAN configured on the UC320? Is it configured as a static IP or as DHCP/PPPoE? If the latter, then you could still be having the interface effectively go down even though it does not physically go down. DHCP is likely to be a problem unless you are using ridiculously short lease times, but a PPPoE connection could flap due to issues out in the network.