Help with back to back PRI's on a MICS

Hey guys I lurk here now and then but haven't asked for help here until now, my problem is this

I have an up and running Nortel MICS with one DTI card that's been working on Bell Canada's NI-2 service for 3-4 years - I have had no trouble with it and it's running fine

I'm trying to run some VoIP experiments on this switch just to learn (I'm lucky to have access and use two of their DID's). So I've added a second DTI card and have the ISDN side running. My big problem is how to I setup the MICS to allow calls from the second PRI (to my Cisco VoIP router) to go out through the first PRI over the PSTN. The link is working and as I expected when I dial digits and try and complete a call on the second PRI it just goes to prime once it times out, or to the matching target line of I put in the correct digits


Bell Canada/PSTN | -> MICS -> Cisco VoIP router

I need to complete calls through the MICS back to the PSTN

Second. What's the best way to forward the calls from the PSTN to the Cisco is it using routers , or do I need to do the target line/redirection thing

I have outgoing routes setup but is there anyway to define a route that get's matched and forwards between the two PRI's for incoming ??

I have a route now for outgoing calls, which has been working. When I place a call on the second PRI that would match the route it still get's treated as an incoming call. It seems this would be the moste elegent way. Is it possible ?

Please don't be afraid to overwhelm me with all the details you happen to be thinking about, in fact I prefer that. I'm not shy of details and I have lots of DCOM experience, I'm not a 'Installer' however I help out allot of small comanies in my area so I end up doing the installs for them because their isn't anybody here that has any hard core info about PRI's

The Cisco says the D channel is up and I can complete calls, so I assume I have the ISDN side at least half configured - even if I don't I can limp along and get that working myself ( I think) I need some clues for handling the outgoing calls

Thanks in advance, Adam

Reply to
Loading thread data ...

One more thing, I was reading the installation guides a little more

It looks like SL-1 and T1 as a Tie-Link will support what I want, is this correct ?

It seems there's no way to pass calling, and called number with Tie links is this correct ?

For going from the Cisco to the PSTN. If I where to define an autoDN / or DISA is there anyway I could automacily pass the digits I want to dial next on the same string. The manual implies that the digits after the disa DN could be used for something - I'm not sure what. I pass inband signalling after I get to the DISA so I dunno what todo if I can't, so can I ?????

Even though I can have calls coming from the Cisco that get matched aginst the target lines and they seemed to work fine (more then one call) when I try the annoited destination code for the second PRI the MICS says 'No lines available' however when I'm looking at L2/L3 on the wire I don't see anything going across the PRI D channel - any hints ?

A little more on what I'm trying todo in case it helps

I have the MICS connecting through and PRI to the PSTN through one PRI DTI I have a Cisco 3810 IOS12.3-9d with a DVMT1 going to the MICS through another DTI

I want to be to make/receive calls from PSTN and bridge them to SIP for VoIP I want to just be able to pass calls through the MICS. The installer guide has examples but as far as I can comprehend none using anthing other then the SL-1 flavour of PRI - is this correct ??

Reply to

Let me see if I understand this correctly: You have one MICS with two DTI cards one going out to a Telco network and the other one to a Cisco router and you want originating calls from the router to go through the MICS and out the PRI. Is that correct?

Reply to

I would look at answer with disa and start there.

Reply to

I've been playing with DISA but I can't see how to make it work DISA needs a COS password and how would I pass that automaticly on the ISDN dial string

autoDN seems like it hold most of the potential, however I still can't seem to pass the autoDN dialed number, in combination with the number I want to access from the autoDN

The installer guides for MICS SW Ver 4-6 states that the trailing digits when your dialing a autoDN can be used but I'm unclear on the way I can be used.

I have the 'problem' with the busy lines fixed, I made an error with the outoging routes

Also to foward calls from the PSTN/first PRI to the Cisco/second PRI I tried setting up a target line to a specific DN, then forwarding that DN on no answer and busy to an external (second PRI pool code) but it's 'busy' what I am doing wrong How should I do this ? I have line redirection turned on

The big problem as I see it is that I need to complete the entire call through the MICS through one ISDN setup message. I can't place a ISDN call to a DISA/autoDN then though tone in the digits I need to place. It seems I should be able todo what I want but I don't understand how yet

Reply to

Yes I want to use the MICS just as class as I can to a transpeartant link to the PSTN

I want to make calls from the Cisco and have them passed from the MICS to the PSTN I also want to recieve calls from the PSTN and if the delieved called party digits match foward them to the Cisco

I currently have L1-3 setup correctly (I think) for ISDN. I can manually make and receive calls going through the Cisco to the MICS and it tried to match the DNs and if it doesn completes the call to the correct DN (everything sounds fine) and if no DN match it forwards it to the prime setup. I also can make calls on the MICS and use a poll code to get out to the Cisco and place calls to the Cisco that way, once again everything seems to work and sounds fine.

Now I need to get things forwarding through the MICS automaticly for incoming, and outgoing calls. The installer guides as some examples. But the closest configs that will do what I want have either T1 as E&M/DID's (no good - no caller ID/called party ID) or SL-1 (the cisco doesnt support this pseudo-standard ISDN protocol).

Reply to

I understand you're just testing; in a large implementation DISA poses very significant security risks. I'd strongly discourage using DISA for this application.

I'm not incredibly familiar with mics, but I've been an M1 Opt

81c/Symposium/CTI engineer for a while. Could you perhaps set up your inbound DN as an ACDN & NCFW to the DN that goes out the cisco?
Reply to

Look @ Remote access packages. set all of your Telco PRI channels into one line pool (i.e. PRI-A) and set all your TIE channels into another line pool (i.e. PRI-B) place both line pools into the same remote package (i.e. Remote Package 01) the rest is all call routing and destination codes.

Reply to

I realize the implications of DISA, there's a COS password that only I know so I don't see any problems happening. The autoDN seems to be more of a risk however I have it setup ith the remote access packages to that the PSTN users can't autoDN back out to the PSTN - which is the only real place I think there would be a risk of toll calls

Reply to

I thinks configuration their all PRI's there are no Tie's. Both are NI2 ISDN

I have setup the remote access packages, for the incoming PRI from the PSTN I have the package setup so that I can only get to the second PRI (hence disabling the ability to make toll calls back out through the autoDN/PSTN) and on the second (Cisco/NON-PSTN) PRI I have the packaage setup so I can access both the PSTN PRI and the Cisco PRI ( I don't know why, I figured that I may use the looping back through the autoDN back to the Cisco for test purposes)

Now, with two NI2 PR'sI is using the autoDN the closest I'm going to get to dialing 'through' the MICS. Is there anyway to use CbC routing, dest codes etc so that I call coming in from the second NON-PSTN PRI can get routed back to the PSTN though the MICS ??

And I'm having tons of trouble 'forwarding' the call coming in through the MICS to the second NON-PSTN/Cisco PRI

autoDN'ing works fine, however when I setup a target line private to an extension and set said extension to forward on no answer and on busy the call gets forwarded out to the line pool and the correct destination on the PRI but it seems the MICS disconnects the call (with a normal cause code - wierd) within a few seconds of forwarding. It doesn't matter if the forwarded call is still ringing, or it's been answered it still disconnects the call. What am I do wrong is there anyway way to forward a call coming in on the PSTN/First PRI back out to the Cisco/Second/NON-PSTN PRI ????

Thanks again, Adam

Reply to

OK if you want to do this right, let's start over.

Let's assume you have a MICS 6.1 or newer. Let's assume there are 2 PRI's one (PRI#1)comming from Telco the other (PRI#2) comming from privatly owned Cisco EQ. Let's assume that the extention numbers on the Norstar are DID and start at

2221 thru 2821 Let's assume that the extentions on the privatly owned Cisco EQ. start at 4221 thru 4821

-First seeing as you own the originating equipment on PRI#2 you can determine what protocol this PRI uses.

-Second decide which piece of equipment will be the master clock of PRI#2. Will it be the Norstar or the Cisco?

Set up PRI#2 at the Cisco so that it uses NI-1 or DMS-100 protocol. This is a custom propritary protocol that Nortel invented it allows for private networking where as NI-2 is generic North American Standard.

If you use the privatly owned Cisco EQ. as the master clock for PRI#2 then the Norstar must use PRI#2 as it's secondary clock source with PRI#1 being Primary Clock Source. If on the other hand you decide to make the Norstar the clock reference for PRI#2 then you must set the Norstar to use PRI#1 as Primary Clock Source and PRI#2 must be Master Clock Source.

Set up PRI#1 as B8ZS ESF NI-2 and PRI#2 as B8ZS ESF DMS-100 Set up PRI#1 as Line Pool PRI-A and PRI#2 as Line Pool PRI-B Apply Restriction Filter to PRI#2 to restrict Long Distance calling from PRI#2

Build target lines with receive digits for DID numbers and assign them to the corresponding extensions. ( I like to make the extension numbers the same as the receive digits and assign the target lines as Ring Only) This will happen automatically if you initialize your system as DID.

Steer by Receive Digits (DINS) only. Do not prime any lines (physical or target) to any set. Do not build any DISA auto answer or auto DN extentions.

Next build Route Tables Build Route 001 as public route using Line Pool PRI-A Build Rout 002 as Private route using Line Pool PRI-B

Check Line Pool Access Codes to make sure that there are no Line Pool Access Codes Built. If there are any, remove them. We want to steer out bound traffic by destination codes not access codes. Also if there are any external access digits assigned, remove them.

Build Des codes for routes 001 and 002 first Des Code will be 9A using route 001 with an absorbed digit length of 1 (A means Any) Next Des code will be 42A using route 002 with an absorbed digit length of 0

Des code 9A will allow you to place a public call using 9 + NPA-NXX-xxxx the absorb length of 1 will absorb the 9 so that it will not be passed to the Telco. Des code 42A will allow you to call any extension in your Cisco beginnig with 42 as if they were extensions on the Norstar.

Place both Line Pool PRI-A and PRI-B in the same Remote package 01.

Any Received Digit coming in on PRI#1 will Route to PRI#2 if the receive Digits start with 42 as per des code 42A therefore extensions on Cisco can be DID also.

Reply to

First thankyou very, *very* much of help - your the only one that's givin me any help and it's valued very much

Okay so I've already had the PRI and the clocks setup. I'm using ESF and B8ZS on both PRIS. Currently I'm using NI2 on both, I have to use NI2 for the PSTN connection to our carrier but would I be better of using DMS100 protocol between the MICS and the Cisco ??

I've already setup the remote packages like you suggest, however it was to get DISA / autoDN's to work however I'm going to disable them as you suggest

You mentioned Steer by Receive Digits/DINS is this a MICS SW6 only feature or is it just a term used for setting up the MICS as you describe

So, I realdy have dest codes and routes the way you suggest as are the remote packages. However when I enter dial an extension DN from the cisco it just goes to prime, and when I make a call with a number that should match a route it also just goes to prime. On your message you said set route 002 to 'private' however I don't see that option.

Does this private option let the calls from the Cisco match against the routes ? All the routes seem to be setup, or at least the routes match and work the way I expect when I'm dailing from a setup on the MICS. However my

*big* problem is on either PRI it doesn't seem to match the incoming digits against the routes. What I am missing, this is my big sticking point. I believe the software in this unit is 5.X however it could be ver 4.

Thanks, Adam

Reply to

Hi Adam:

I believe this routing method has been in use since version MICS 4.0 so it should work on your set up. The reason you don't see the private option for your route 002 is because PRI#2 is currently set to NI-2. NI-2 does not support private networking DMS-100 does. I would change PRI#2 to DMS 100. Also check your dial plan settings. If you notice you have public and private dial plans. make sure your private dial plan has the same dial length as your stations. In other words if your extension numbers are 2221 then your private dial plan would be 4 if there 221 then your private dial plan would be 3, and so on. (This setting should match with DINS Digit length.)

Steering by receive or DNIS digits is the method I prefer to use because its easy to keep track of. Prime lines can go to odd places if you lose track of whose prime to what. So I prime nothing not the PRI channels not the target lines NOTHING. if you look under your target line settings you will see at setting for Receive Digits this is were you can define your receive digits for that target line. There is also a setting under System programming to set the length of the received digits (2,3,4,5) again I'd use the same as extension length as with private network dial plan, But to be sure ask your Telco how many DINS digits they are sending.

Only make target lines for the Norstar extensions. Do not make Target Lines for the Cisco extensions those get handled by the Des Code.

DINS is received on PRI#1 D CH. first looks for target line match. finding none then looks to Des Code for route to destination connects to PRI#2 with remote package sends call and DINS digits across to Cisco.

This also works in reverse calls coming from Cisco come into Norstar on PRI#2 will send DINS digits to the Norstar so make sure that the Cisco is sending the same number of digits as your dial plan allows. Public calls will start with a 9 which the Cisco must pass to the Norstar. This bumps the Cisco's public dial plan up by 1 digit. Private calls would be the same as your private network dial plan Just out of curiosity what end is the source clock on PRI#2 the Nortel or the Cisco?

Reply to

Okay done I have switch the PRI's ISDN type to DMS100

Okay I've removed the target lines, when I defined the destination code when I select the type of route it also let's me select the 'next/top right' programming button which then goes into a submenu where I can assign which would match as 'assigned', 'avail', 'unassignable'. However I think this may be because I have some other real target lines that I need to keep in the same range. So 4125 I need to keep to a target for now, but I assigned


Done. I have one target in that range going to to another Cisco with analog cards that I'm playing with for now to accepting/make calls through this MICS. Once I have the PRI working the way I want then I'll just drop that target and then 'assign' that DN in the destination under the schd part

Yeah, this is the part that I was stumped on - it wasn't match the above recieved calls to any of the dest's on the PRI that's going to the Cisco, when I change the Cisco to DMS-100 and the route type to private now it will forward calls through. I was getting _really_ worried that Nortel decide that the MICS would only internetwork over PRI's with the SL-1 protocol. The book I had didn't include any NI1/2 examples, but now I know why (thanks) the NI protocols don't support private networking

Cool this is exactly what I wanted, thanks very much again I've setup the MICS to have the PSTN PRI from Bell to be the Primary and then the Cisco as secondary. I've then assigned the PRI coming _into_ the Cisco as the primary clock. Is this the right way. I mean if the PSTN fails then the Cisco would be useless, but what happens when the MICS primary fails and then it tries to use the Secondary (which is only timed off the MICS) as primary ??. I had the choice of secondary or TimMstr which didn't seem like a better idea then secondary. What do you think ??

Okay now the big question, Bell is sending 7 digit dialing over their PRI. Here I have to keep three digit DN's for the sets. So the rcv'd is set to 7 and local is setup to 3. This hasn't been a proble so far but I think it's causing my next minor-ish problem. When I get an incoming call in the PSTN PRI and it matches the dest/route codes it forward to the Cisco no problem. However there's no calling party ID, and the called party it is just the first 3 digits of the forward destination. I assumed this is because the MICS trunc's because it and drops it down to match the 3 digit local DN's. Is there anyway to get it to preserve a:)the calling party info from the PSTN PRI b:)the full called party. It wouldn't be *that* big a proble except the MICS is only sending the

*first* three digits of the called party instead of the last three. So the called party info sent to the Cisco is always on the exchange..... humpf .....

Thanks, Adam

Reply to
7 DIGIT!! Why did it have to 7 Digits? This complicates things.

I think we might have to up your Private Network Dial Plan to 7 Digits.

You will also have to make Des Codes that include the Prefix.

This is what's happening. Your Telco is sending a call to you with DINS of

555-4121 for example. The Norstar recieves that string and starts looking for a digit match first it looks to Target lines if there are no defined lines then it will looks to Des Codes to find a match. We will need a Des Code of 55541A and the private network dial plan needs to support all 7 digits or it will chop off the rest of the DINS.

goes into a submenu where I can assign which would match as 'assigned', 'avail', 'unassignable'<

These are called "Wild Card Digits". take 555-4125 for example. If you build a Des Code of 55541A then look at the Wild card Digits for that Des Code all of them would be assigned exept for digit 2 that would be "unavailable". So then you would have to build another Des Code of 555412A if you then examine the Wild card Digits of that Des Code all of them would be assigned exept for digit 5. In this way you can isolate a DN out of a range of off premmise extentions without having to build a Des Code for each off premise extention. All wild card should be either Assigned or Unavailable. You would only change a Wild card Digit to Available if you wanted to build a target line were it is currently being used.

and then the Cisco as secondary. I've then assigned the PRI coming _into_ the Cisco as the primary clock. Is this the right way. I mean if the PSTN fails then the Cisco would be useless, but what happens when the MICS primary fails and then it tries to use the Secondary (which is only timed off the MICS) as primary ??. I had the choice of secondary or TimMstr which didn't seem like a better idea then secondary. What do you think ??<

Set the Cisco as TimMstr. Someone has to provide clocking for PRI#2 and if like you say the Telco Primary fails then the Norstar would clock off the Cisco keeping at least this private equipment talking to each other. I'm assuming the Cisco has access to a NTP Time beacon server on the internet to keep its clock in sync.

Reply to

Hmmm, uping the private number plan to 7 digits won't be doable, at least not yet I'm just testing a VoIP for me to learn, and hopefully getting the company that has the PRI on board with VoIP down the road. I can't really make any changes that would 'affect' them in any meaningful way. I need to keep the DN's at three digits for the users, however I'm going to thinker with using routes/dest's and such to try and map the digits that they dial onto the 7 digit local DN's - however that's a last resoft I can't not see that getting messy. They have a Startalk they use a AA, intercom calls through the office..

As the MICS truncat'ing digits I have the dest code for the Cisco set to:

328412A, when the MICs receives 3284123 from the PSTN it passes to the Cisco as '324' not matter when wildcat it matches. When you say I need 7 digit dest. Does this mean that I'll not be able to use the wildcat. Or is the 7 digits inclusive of the wildcard and my problem lies elsewhere

I'll also set the Cisco to Master, however my one concern is that if anything goes wrong with the Cisco in *any* way it can't knock out the MICS. I'm less concerned with the Cisco talking to the MICS in the event of a PSTN PRI failure, I'm VERY concerned with the MICS failing to talk to the PSTN if the Cisco fails. It would quickly lead to the termination of my experiments with this switch, it's a running switch and nothing I do can interferre with the normal operations

You have Paypal? You saved me an immense amount of time and effort. I dunno how long it would of taken with my tinkering around. I won't have money for a little bit but when I do I want to paypal $100 US. I figure your help is worth at least that to me

Reply to

OH 7 digts why did I have it as 7 digits, because:

a:)Bell passes that many b:)I also try and always think forward and at the time I didn't see the downside of keep digits, however I did see complications about throwing digits away. To tell you the truth I have no 'real' idea of how 'it's done' because I normally have talked companies that I've helped with IT/Linux servers, network eng'ing into upgrading to PRI's solely to save money. I've found that the local installers are underskilled (not many PRI's around here), overcharge and aren't really concerned with making the best use of the customers equipment and saving whatever money is possible monthy and on capital equipment. I also enjoy it I've learn ALLOT of telephoney/telecom since I've been doing that. I'm somewhat limited my some health problems (tumor affecting heart - not around heart - long story) right now so I don't really do this 'for the money' I just do it to learn. However in the last year I've gotten to setup 38Ghz microwave links, many ATM networks, Asterisk servers, channels banks, DS3's/T3, DS1, I have learned SUN's arch cold, have learned tons abotu SGI's/IRIX, I've setup a DSLAM running a private DSL network in a dorm with 200 users and so on. So since I don't just do it the 'standard' way sometimes I do things kind of goofy (since I don't _known_ the standard way)

In the future I hope to have the Asterisk VoIP server that I'm testing bridge this MICS with all their remote offices. They have offices in the exchanges of 887/324/328/738/878/879. The of the last 4 digits are the same for the main numbers (we deal with older people so I figure keeping the last 4 digits would help them out), having 5 digit DN's would conflict witht the 878/328 exchanges, so I figured while I have to have 6 why not go for 7 and retain all the info it was passed. I've done 4 other PRI's on MICS for various companies I've helped out and I've always done 7 digit dialing, and I always avoid anything that's throws away any info I could ever picture using. In in the future I think I'll keep the DN's to 4 digits in this case I want to keep it as long as possible to perserve as much as the routing information as possible

Thanks again, Adam

Reply to

I'm just testing a VoIP for me to learn, and hopefully getting the company that has the PRI on board with VoIP down the road. I can't really make any changes that would 'affect' them in any meaningful way. I need to keep the DN's at three digits for the users<

Private Network Dial Plan has no effect on DNs or customers I Just is the number of digits you can Dial before the switch stops excepting them and sends them. Look under System Programming / Dial Plans

Reply to

Oops I forgot.

I don't think there is any way the Cisco could mess up the MICS after all it's ingnoring the Secondary Clock when the Primary is on-line.

Don't worry about the paypal thing. This is what groups like this are all about. How many others will read these posts and learn from them. Knowlege sould be like air, just there for all to share. If I wanted everyone to pay for everythig I did and said I'd have to call myself Bill Gates.

Reply to

Oh thanks very much but if you want some drinking, misc hednostic thrill seeking, or gas money to go to church just let me know. I'll forward a little part of my piggy bank to you, your help is very valuable to me. Eh, well.. You now that we're talking about help and all. I'm still one a little problem that I'm hoping you can help me with. This morning at 5-7AM when I was reprogramming the MICS with regards to your recommendations I made an incoming call from the PSTN to a number which mapped through a destination (aside from the number getting trunc'ed to 3 digits) I figured all was good. However I'm still having a problem, when I start a call from the Cisco it fails. It doesn't match against the Dest codes and just falls to prime after the timeout. Is it possible because the Cisco isn't setting the private flag on the call ??

Here is the Q921 debug from the Cisco: Transfer Rate = 64 kbit/s Channel ID i = 0xA98381 Exclusive, Channel 1 Display i = 0xB1, 'Adam Dickson' Calling Party Number i = 0x0080, '2228' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '93245500' Plan:Unknown, Type:Unknown

02:48:22.738: ISDN Se1:23 Q921: Net RX
Reply to
adam.dickson Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.