Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DID from one MICS over T1 to second MICS and then to VM 2

Status
Not open for further replies.

chirkware

IS-IT--Management
Jan 17, 2006
80
US
Here's what I have:
Two MICS connected via T1 (PRI enabler on both). Each has its own CP150.
System A is MICS 7.1 with a PRI from AT&T and 60 DID numbers.
System B is MICS 7.0 with 12 POTS lines.

I just had three users move from the building with System A to the building with System B. They want to keep their DID numbers.


My Hasty "solution" (work around) was this: I enabled their old phones to CFNA and CFB to their new extension numbers, then put the phones off hook so the CFB would take effect immediately. This worked in that their new phone on System B would receive calls that came into System A via their DID. Unfortunately, when the new extensions CFNA kicked in, the call would go to the General Delivery mailbox instead of their new voicemail box (calls directly to their new extension go to VM as expected).

Here's the path of the call: Call comes in on DID 555-5113, system sees received digits of 113 (three digit extensions on both sides). Line 173 is Target line that takes Received numer 113 and is Private to 113 (prime set for Line 173 is also 113). DN 113 has Line 173 as Ring only, so call rings to DN 113. CFNA/CNB says forward to 375. 3 is destination code for calls to System B (absorb length is 0), and is routed over the T1 to system B. System B sees received digits 375. Line 275 is Target line that takes received number 375 and is private to DN 375 (with prime set 375). DN 375 has Line 275 as Ring only. DN 375 rings...Four rings no answer? OK, CFNA to 349 (DN for System B CP150). CP150 has mailbox number 375 defined and activated with extension 375 assigned to it, but places it in the general delivery mailbox...Grrr.


I'm not sure why that happens, but ultimately, it would be nice to not waste three phones and three extensions on System A just to make CFNA/CFB work, even if I can fix this above. (I believe I am correct in that there must be a phone connected to the DN for the CFNA/CFB to work.)


Is there a better way to accomplish this? I'm thinking it could all be done by routing, but I can't get my brain around it.

Thanks!

---------------------
I'd rather learn from other peoples mistakes than have them learn from mine!
 
Yes ... routing is the answer.
When a call arrives at the Norstar, the Destination Code list is the first place the system will try to match up digits.
Remove the recvd numbers from your target lines.
Change the DN's to something out of range, maybe 713.
Configure a new route, maybe 913. Configure the route dial out/external number to 375.
Configure Des Code of 113 to use route 913 and absorb all.
Call should be answered by the system, matched to des code 113. The 113 will be removed and 375 will be added and sent to site b.

-SD-
 
SupportDude,

Thanks for the help...that makes a lot of sense, and I'm closer now, but still not quite there.

I used 140 as a test since I had already changed that DN out of range and thus had 555-5140 as an unused DID.

I created Route 140, Gave it external number 321 (my extension on Site B), set it to use Pool PRI-A, and DN type Private. I created destination code 140, and set it to use Route 140 with Absorb Length All.

If I call in the main number for Site A, get the AA, and dial 140, I get routed over to 321 on the other side, and get to 321's VM box at the end...excellent!

However, if I dial the DID 555-5140, I'm getting a fast busy, so that makes me wonder if an outside call coming in can go directly to a destination code...hopefully it just means I have some more programming changes to make. :) Any more suggestions?

Thanks again!

---------------------
I'd rather learn from other peoples mistakes than have them learn from mine!
 
cook1082: There is a target line for received 321.

I can dial 321 (at Site B) from Site A with no problem. I can also dial 140 from any phone on Site A and ring 321 (or dial Site A's main number and dial 140 when I get the AA and ring on 321).

The problem is, when I attempt to dial the DID number formerly associated with DN 140 (and there is now no DN 140), I just get a fast busy. That's the problem I'm now trying to solve.

---------------------
I'd rather learn from other peoples mistakes than have them learn from mine!
 
Try this
Take the Target Line that you have in site A put it on a phone.
Then use Line Redirect (F84) to Route that Target Line back out to Desti 140.
Test it if it works then you cna remove that Target line form the phone and it will continue to work until you turn off redirect for that line.
 
Hawks,

It's funny, I just found faq799-3640 which described the process you just posted. It works! My three folks who moved have their DID's staying with them now.

So, once the Line Redirect is done, you say I can remove that target line from the phone. Will that still work correctly if the target line winds up with no phones associated with it?

I'd like to take the three extensions formally used with these DID numbers and change their DN's to make them usable for other purposes. So it sounds like I can now remove the target lines AND change DN the three extensions and all this will still work. Correct?

I'll definitely need some good documentation as it would be a head scratcher in a year or two why those digits do what they do.


Thanks to all!

---------------------
I'd rather learn from other peoples mistakes than have them learn from mine!
 
Glad to here it works
Yes you can remove the line from the phone and it will continue to work until someone adds the line back and turns off the redirect. I've got a couple set up this way now for going on 3 years.
But yes please do keep good records because you are right in a few months trying to troubleshoot someones number could be a nightmare if you forget what you did.
 
Sorry Chirkware ...
I always forget this ... you needed to build a remote access package on System A that allows your PSTN line pool to access your private PRI line pool. This is why you were getting the fast busy.


-SD-
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top