VoIP phones getting back ip address: problem with dhcp zone or vlan

I have some Mitel IP phones that are giving me trouble on a network I recently inherited. I literally came in on for my first day supporting the system on Monday 12/28 to find the fiber connection to the building had been down since the day before Christmas. Thankfully almost everyone is out this entire week. That link is back up now, but the IP phones in the building will not get good IP addresses. I'd really like to have things back to normal by Monday. I came into this knowing very little about the setup, but here's what I've been able to turn up on how things are configured at the moment:

• The phone system uses a separate vlan from the computers (of course).
• Each phone shares a wire with the computer at the desk (the computers plug into the back of the phone). That's typical from other environments I've seen.
• The switch at the building (a 3com superstack 4200) doesn't have any apparent ability to configure vlans per port itself, but is supposedly at least vlan aware and should pass on vlan tags for me.
• This remote switch talks via a fiber link to a 4900SX fiber switch in the server room across campus that can manage vlans per port; each port can be tagged, untagged, or not a member of a vlan.
• The 4900 is configured with the normal/default vlan untagged for the remote link, and the phone vlan tagged. This sounds right to me.
• The phones vlan is on a completely different subnet than the default vlan. I mean, 192.168.xx vs 10.x.x.x, so it's not even close. Addresses for both networks are served from a single Windows Server 2003 dhcp server, with a different zone for each vlan.

The problem is that the phones can't get a valid ip address. Here's how I understand things are supposed to work:

• A phone starts up with a basic configuration and requests an ip address via dhcp.
• There are no vlans set on the phone yet, and so it should get a response with an address from the zone on the default/computer network.
• This zone is configured with a few extra options that the phones recognize.
• The phone reconfigures itself based on those options, releases the old invalid ip and requests a new ip address, this time tagging it's frames with the correct vlan.
• The 4900 switch should see the tag, and this time when it forwards the packets to the dhcp server they'll look like they belong in the dhcp zone for the phone vlan.
• The dhcp server sends back a response for the correct vlan, and the phones are able to connect to the VoIP pbx correctly.

What I watch them boot up is they get the first ip address and reconfigure with the new vlan, but then are either unable to get a new address or continue to get an invalid address and end up stuck in dhcp discovery mode, endlessly retrying the request.

Any ideas about what might be wrong or how best to troubleshoot this are appreciated. Also, it seems to me like a little magic is happening with either how windows decides which dhcp zone to use (at least be default) or how the 4900 switch indicate which network the phones vlan packets belong to, so more information about how that works is appreciated as well.

My gut tells me the problem is in the 4900 switch, since that's where the solution to my first question was and that seems to be where "magic" is (it's supposed to make layer 3 decisions about which network/vlan a frame came from, but I can't see where to configure that).

Update for Dhcp options:

128 Tftp server 192.168.#.#
129 RTC IP Address 192.168.#.#
130 MITEL IP PHONE
132 VLAN ID {phone vlan id}
133 Priority 6

These are set on both zones.