Switch DID Number for a Line 2

[jpang102]

We have a Norstar System that is using PRI along with DID numbers. Recently we have to switch the DID number of a phone line due to people moving offices. In short, x2001 now becomes x2002 and vice versa. I can change the DN's of the two lines by going to Terminals & Sets -> System Programming -> Hunt Groups -> Change DNs. Internally, everything seems to work fine. Even phone display shows correctly after a DN change.

However, when I called the DID number of these 2 lines, calls are still routed to the old phones. I have been looking everywhere but was unable to find out how DID's are being routed. Any help would be appreciated.

 

[madwok]

You probably need to check the target lines.

 

[richitguy]

For a simple change like this you probably should have swapped jumpers at the frame or used Set Relocation (I think it is under features in system programming)-- turned it on temporarily, moved the sets then turned it off when finished. but now with the DN changes you have executed, you will need to do as madwok has suggested and swap the target lines that appear and ring in set programming

 

[cook1082]

A DN change only changes the DN's all other programing needs to be moved from one set to another.

 

[jerryreeve]

Think of it like the actual programming is done on the PORT of the system that will help you keep in mind for the future what you have linked that would have to change.

----------------------------
JerryReeve
Communication Systems Int'l
com-sys.com

 

[RikRodgers]

All correct. To get things straightened out, it's probably easiest to Change DN them back to what they were, then turn on set relocation, and swap the sets. Make sure to turn it off when you're done.

 

[jpang102]

Thanks everyone for contributing your idea. Like RikRodgers said, they are all valid. To a novice like me, it is easiest just to use "set relocation". When I did my web searching yesterday, I found that some people did not like using this feature. They said it would throw documentation out of the window the moment you started to use "set relocation". Instead, they recommended making changes on the cross-connect.

To me, both options are fine. I have the tools to switch the jumpers. The system we inherited does not have any documentation. I am not sure what kind of harm "set relocation" will cause.

 

[Deweyhumbolt]

Way over done. Techs want to have to come out and get paid. I tell every customer to use it, just don't do too many sets at a time. Rarely, had a problem.

Follow Riks advise. Easiest, cleanest way.

Adversity is Opportunity

 

[stevethephoneman]

Using set relocation, if not just 2 phones at a time, same type sets, wait 3 minutes before unplugging these. Then proceed further until finished.

Then TURN SET RELOCATION ...OFF.

If left on people will switch sets around on their owm, too many sets, or not same types, or not waiting for them to come up on their own.
You will have your VM system crap out on you. I have seen it happen too many times in the last 18 years.

That it why I have been installing my systems on patch panels for the last 8 years. It costs the customer a little more up front, but they can do their own moves (once you show them how it is done they are not afraid) & the port, ext, & lines are always in place.

 

[RikRodgers]

To be honest, I'm not the biggest fan of set relocation either, but it does have it's uses.

When a customer specifically asks me to train them to use it, I will. Set model type doesn't matter, but I advise them to swap only 2 sets at a time and wait for them both to come up before swapping any others. Mass moves, as many sites are prone to, can really screw up their programming, and require a site visit anyway.

The true rule of thumb- the first set you unplug should be the first one you plug in. And TAKE YOUR TIME. Wait for the sets to come up before moving on. Always disable it when done.

 

[MarvO1]

I have to agree with RIK, it's not way over done. Set Relocation has its place on small systems, but not on a wide scale. It's not that techs want the MAC work, they want happy customers with stable systems. Much of my work is done remotely via RAD and it is very time consumming to to sort out port numbers instead of ext. numbers. My rule is: "Never unplug more that 2 sets at a time"
I do admit that I have never had a system fail because of Set Relocation.

MarvO said it

 

[Deweyhumbolt]

I keep hearing that Set Relocation is a problem. I've been moving Norstars since 1995. From 3 sets to 140 sets. Before I take the switch off the wall, I turn Set Relocation on. I tell the customer, I'm going to move your Recpt. telephone, and the phone room telephone.

I put the switch on the wall, x-connect, station jack to open port, of course the recpt. set on port 101. Install recpt. telephone with or w/o KLMs. Then over the weekend as they unpack their desks they plug their own telephone into a hot jack and voila, there own telephone has their own programming just like at the old office.

That's all the telephones, not just two at a time. Allot of times 4 people at a time are plugging in their telephones. Never had a problem. I guess I'm just lucky.

I agree, allowing the customer to use Set Relocation can cause big problems. But, as a vendor tool, Priceless.

Adversity is Opportunity

 

[madwok]

Last month, I just moved one of my BCM400 v4 with over 70 stations and use set reloc without any problem with 5 of us plugging phones left and right . ( Mentatlly prepare for the worst but I got 2 back up so why not ? )

Coming from Opt 11, I can tell you that if you do with this scale, the software WILL corrupt. Did twice on Opt 11 and my Nortel tech has a fun filled 2 days to fix it .

 

[Deweyhumbolt]

Fully agree, M1 product forget you ever heard of the feature. But, Norstar/BCM, go for it.

Adversity is Opportunity

 

[jpang102]

I was convinced to use "set relocation". Unfortunately, I ran into trouble even before making any changes. As I have never used that feature, I turned on "set relocation" the first time just to observe. Then a minute later I turned it off. The moment when I press "Rls" after finishing programming. I saw the "Update" display. It showed that 5 DN's were updating. Finally, when it counted down to 1, "Update" stayed forever.

It is showing an extension number which is no longer in use. I don't know which line the number was programmed to. The update never finished.

 

[Deweyhumbolt]

Update means nothing. Turning it on doesn't do anything, unless someone moved a telephone during that time, w/o telling you. Change DNs back, turn Set Relocation on, move tels where you want them, WAIT, for them all to come back up. Because, it will appear they've come up, but you can't make calls. When they can make calls turn Set Relocation off. Done.

Adversity is Opportunity

 

[jpang102]

Thanks for the explanation. I have set relocation off for an hour already. No phone sets have been moved during that time. However, my phone still showing "UPDATE". When I press the softkey beneath it, it displays "DNs Updating:1". Then I press the "DNs" softkey, it shows "DN 4353". We do not have this number in use any more.

How can I get rid of the "UPDATE" display?

 

[Deweyhumbolt]

Like I said it means nothing. But, you could unplug your set than plug it back in. (30% chance)

Disable/Enable the port x4353 resides at. (75% chance)

Reboot Norstar KSU. (100% chance)

I'm taking for granted you've dialed that DN an get "Not in Service".

Adversity is Opportunity

 

[jpang102]

Deweyhumbolt,

I rebooted the Norstar system. The Update message disappeared. I was told that the extension number was not in use. However, it was picked up by a VM greeting when called. I am going to leave it alone for now until I have to reuse the DN.

Now I run into another issue of having an extension number which does not forward to VM properly. It was set up to do "Forward no answer" and "Forward on busy" to VM. But I saw on the display that it forwarded to an non-exist extension. The call disconnected immediately when no answer.

I checked the settings under "Capabilities", both "Forward no answer" and "Forward on busy" were set up exactly the same way as other numbers. No matter how I change them. There was no effect at all. I even cleared the number once. It still forwarded to the unknow extension.

The strange thing is that after rebooting the VM, it worked once. Call no answer was forwarded to VM. I heard the correct greeting. But then on another try, my call was forwarded to an unknown ext and then disconnected.

I am not sure if deleting and re-creating his VM box will help. I think the chance is slim because calls are not forwarded to the VM system. His mailbox does not really matter.

 

[jpang102]

I have more info regarding the VM problem just mentioned. An extension number is not forwarding calls to VM although "Forward no answer" is checked to be set up correctly under "Capabilities". Later, I tried to change the no. of rings from "4" to "3". It started to work.

I think somewhere there must be a default forwarding (to an non-exist extension) set up on "4" rings. This settings somehow interfere with VM forwarding. How can I find out more about it?