IP phones with identity crisis

[Alboski]

Hi There..

For some reason my IP phones accross the network will not accept their IP address correctly. The DHCP server allocates the IP lease but the phone sits there stuck on "Starting DHCP".. When I force my way to look at the IP settings, it still has the old DHCP settings on the phone. If I manually allocate the IP address and subnet, it can talk to the meridian system fine..

Has anyone seen such a thing and recovered from it??

 

[Firebird Scrambler]

I had this problem on some very old I2004 phones. I think it might have been some corrupted firmware as I tried all sorts of ways to get it to work and I just left it with it's local IP and gateway address set, but the S1 to be off the Sig Server.

All the best

Firebird Scrambler
Meridian Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[gwebster]

First advice is to upgrade to the latest firmware. There were new versions released last week.

After that, you may need to look at VLANs, DHCP scopes (on voice/data),... to determine what is happening.

 

[Alboski]

Thanks gwebster.

It's strange, the only thing that has changed is the DHCP server (and it's IP address) The DHCP server is configured exactly the same. The VLANs haven't changed because the Virtual server is on the same physical server as the old one.

I'm using a mixture of 1120e (firmware 0624C3G) and 2002 (firmware 0604D9F) IP phones.

 

[Tman45]

YEP!!! Many have called me crazy, but I had this EXACT problem with some older i2004 and i2002. I believe there was some info released saying that they had a bad BOOTP for the DHCP. A work-around was to reboot them many many times and they might connect eventually - I had spent hours and hours on these phones watching them remain stuck on DHCP and working with NetEng's to ensure VLAN, DHCP scope, etc were configured properly. I ended up turning a few of them back in to our sales group and got replacements.

 

[gwebster]

Alboski - C3G is 9 releases old and D9F is 12 releases old. Time to upgrade. Good chance that it will resolve your problem. Latest versions and release notes are on

http://www.nortel.com/support.

 

[Alboski]

Thanks gwebster. Our service provider is updating firmware this afternoon. Will let you all know if it resolves our issue.

 

[riscyrich]

I've had the same problem. Best work around I found was to manually give it the IP address the DHCP server was assigning it, reboot a few times then set back to DHCP. Works 9/10 for my old i2002's and i2004's.

Regards,

Rich

 

[Tman45]

Yep I did the same thing for my work around riscyrich. Annoying that the BootP is bad (I think the bad batch was larger than Nortel claimed) ;D
It gets rather boring watching the 'starting DHCP' screen for minutes on end and rebooting when it finally fails - but then that doesn't clear it and you have to take the work around approach. A 10 minute or less setup turns into almost an hour or more

 

[Alboski]

Hi guys,

Thanks for your support and assistance with this issue over the last few weeks. I thought I was overdue for an update.

The DHCP issue was sidestepped by assigning static IPs to all the handsets. Not ideal, but we were desperate. At least now the 2002 handsets have up to date firmware (full DHCP still wouldn’t work after the upgrade).

THEN On the 20th we were hit with a corruption issue on the processor card. I don't know if this was contributing to the initial DHCP issue earlier but we lost all phones, then only the IP phones after the cabinet reboot. Our support tech told me later that rebooting the cabinet was probably the worst thing we could of done, because there was a good chance that the entire system wouldn’t come back up if the corruption had done enough damage.. I’ll keep that in mind in future, but we’re in the middle of the bush in Australia, so desperate times called for desperate measures.

Now to get any of the phones to work, we have to give it a static IP and manual VLAN settings and let it register. Make sure the switch port is set to tagPvidOnly (after being told that the IP phones will not work unless the port was set to untagPvidOnly).

The strange thing is, the ports were always set to unTagPvidOnly. Nothing has changed on the switches over the last few weeks until now.

It begs the question, is Nortel IP telephony based on the dark arts, or is there some degree of science involved?

Thanks again for your help guys. I have a feeling the initial DHCP issue is not over as our solution for rolling out IP phones is not a sustainable support strategy for our users.

 

[Tman45]

Silly question ... do you have the Nortel designated DHCP string on your DHCP sever? You have to tell the phone what to do with the DHCP string of the format below:

The IP Address must be separated from the port number by a colon ). The parameters for the Primary (S1) and the Secondary (S2) Call Servers are separated by a semicolon (. The string must end a period (.).

For this example, enter the following:

Nortel-i2004-A,10.1.1.10:4100,1,5;10.1.1.20:4100,1,5.
This would equate with the following values;

Call Server S1 = 10.1.1.10
Port S1= 4100

Action S1= 1
Retry S1= 5
Call Server S2 = 10.1.1.20
Port S2 = 4100

Action S2 = 1
Retry S2 = 5

You'll need to configure DHCP option 191 (string) with the following syntax;


VLAN-A:vvvv.

Where: "VLAN-A" Option 191 begins with this string for all Nortel IP phones.
"vvvv" The VLAN ID for the voice VLAN in decimal

Here's an example if I were trying to assign the phones with a voice VLAN of 31;

VLAN-A:31.
There must be a colon ) seperating the VLAN-A from the VLAN ID. The string must also end in a period. It may be necessary, depending on your DHCP server, to enclose the enter string in quotation marks.

How does it actually work?
With the phone and DHCP server configured properly here's how it will work.

The phone will boot up and make a DHCP request for option 191 in the Default VLAN of the port connecting the phone.
If the phone receives a response to it's request it will issue a DHCP Release of the address it received in Step 1.
The phone will make a second DHCP request in the VLAN that was returned in option 191. The phone will be requesting DHCP option 128 from the DHCP server, this will include the Call Server information. (Note: if you use a sniffer you will see that the DHCP packets will have an 802.1q header with the appropriate VLAN ID)
The phone will connect to the Call Server specified in DHCP option 128 and will prompt the user for the Node ID and TN information.
With all that said we did leave out one very important piece of the pie... the network switch configuration. You'll need to configure the VLAN and QoS settings manually depending on the switch vendor.