set relocation - issues?

[hardybob]

probably a dumb question, and i may know the answer, but wanted to ask anyway. i like to use set relocation on remote sites but more experienced techs don't like it because it screws up the correlation between the 66 block (or bix) and the DN in the system. i am interested in feedback to see what, if any, long term effects this causes and problems in troubleshooting down the road.

 

[robl3000]

Set relocation does mess up the correlation between the DN and 66 block, but that is manageable, if your documentation maps system port numbers to the 66 block -- not DNs.

For me, the main issue with set relocation is that it's not always reliable. I have seen problems where DNs get "lost" or changed incorrectly, especially if users are doing a lot of swapping at the same time. For example, on a site I used to manage, I had group of people on the 2nd floor all moving to the 1st floor, and the 1st floor people move to the 2nd. On moving day, people rush to move their phones from the old location to the new. In total there were about 20 phones relocated within about a 15 minutes. We ended up loosing 4 DNs; the system was so confused, it just assigned a new DN to those 4 phones. I had to disable set-relocation, manually change the DNs, and re-program all the features. We ended up with 1 DN I couldn't get back. We were informed by the vendor that the only way to get it back was to reset the switch back to factory default.

From that point forward, I never left set relocation enabled on any system.

==================================
<INSERT SIGNATURE HERE>

 

[curlycord]

I find the only reason it gets messed up is because people relocate sets too fast.
We ask the customer how they want it left, if they want it on then thats what they get, if any issues it's a simple service call to correct.
The only exception is a problematic customer.


I would never worry about the 66/BIX/110 blocks, always use the Port Status in Maintenance.



=--(((((((((()--=
curlycord

http://www.curlycord.com

 

[Deweyhumbolt]

95.7% chance of victory, and if it doesn't work, any technician worth his butt-set can fix it.

Excellent feature for the user.

"Adversity is Opportunity

 

[hardybob]

thanks for the feedback. i only use it where i have the undivided attention of the person making changes and am very specific on unplugging phones, then plugging one at a time in, waiting atleast 3 minutes, testing, then plugging in the next. otherwise i don't gamble with it. i do need to get used to using the port status in maintenance.

 

[telebub]

You can also do a Feature *0, press intercom, press view. That will show you what port that particular DN is tied to.

War Eagle!!

 

[Phonehed]

Set relocation is a great feature and it's very reliable if you use it correctly. The trick is that you have to plug the phones back in one at a time! You must let each phone completely reprogram itself and come back up before you ever plug another one in. Make sure you can actually complete an outside call on the set you just plugged in before you plug another one in. Plugging sets in simultaneously can easily crash or corrupt the entire system! ALWAYS leave set relocation turned off as customers will inevitably try to plug more than one set in at a time!

Phonehed in Dallas

 

[RikRodgers]

Every once in a while I'll get pool buttons disappearing, even when done correctly. I haven't experienced it on newer sw, but if your customer is running R1T1, be ready to talk them through button programming.

 

[Dasheen]

I've been called out after multiple uses of this feature w/ complaints of phantom ringing on sets. End rebooting system and problem goes away.

 

[RikRodgers]

And a few occasions of vm going to wrong ext's. Rebooting has fixed that, too.