Clustar - Using Trunks of another 3300

[TheMitelGuy]

Has anyone ever tried (or are you using) a setup where a user on switch A dials an ARS entry and uses the trunks from switch B? For example I want switch A to dial 9 + number and use local trunks and dial 8 + number to use the trunks of switch B.

 

[Lundah]

Sure, I do it all the time. What type of trunks are you using between the switches (MSDN, IP?)? Faxes and Modems don't like going over IP trunks, but other than that, it's just some ARS trickery to get it going.

 

[MitelInMyBlood]

Without any more detail what you describe sounds like basic ARS-101 to me. Make a route from A to B to send the calls across, then have a route on B to send the calls out. With identical PBXs at each end it should be duck soup. Use the digit mod table to absorb & insert digits as required.

I would make a route list rather than a simple route. That way if system B is down or unreachable the calls will still go out System A. In the route list table maybe even flag the undesired route with warning tone that goes "beep" and pops up a message on the caller's display that says "EXPENSIVE ROUTE" so that you know something's amiss.

What you describe is known in the industry as "Toll Bypass" and is done every day. You cannot legally resell this "service" but for your own internal users it's perfectly legal.

 

[TheMitelGuy]

I tried it but it says "Access Denied." I can't see any restrictions anywhere?

 

[TheMitelGuy]

Trunks are IP between switches and trunk in switch B are PRI.

 

[MitelInMyBlood]

Look at the Class of Restriction table (this is a simple form that intimidates a lot of people)
Look at Class Of Service (public ntwk-to-public ntwk allowed) might need to be set 'yes'
Look at the MAX digits dialed form
Look at # of forward hops allowed
Look at the Interconnect Restriction table
Look at the trunk svc assign form (absorb digits = 0) on the distant end
Look at your ARS digits. Make sure what you're sending across is what the tandem machine is expecting. IE if you dial 9 + the number at both switches then you must send the '9' across the intermachine trunk, whereas normally you'd absorb it before going out your own trunks. If you absorb it in the digit mod table on your end and the far end needs it, well.....

 

[Lundah]

Access Denied" usually means the call was rejected by the telco. Any chance you can take a look at the cause codes on the PRI interface? That may give you some clues. Check your CPN tables. I'm assuming site B has no problems using the PRI locally, yes?

 

[TheMitelGuy]

Correct, switch B has no problems using the PRI.

COR - nothing in there (they don't bar anyone from anything).
Max - don't use
# of hops = 10
Interconnection = they don't use any of that, so it's all at default.
Absorbing 0 in the ARS - appears to be working.
Will double check the Pub NET-2-NET option, but pretty sure it's allowed.

 

[kwbMitel]

Most likely issue (assuming COR is issue) would be the COR assignment for your IP trunks in Trunk Service Assignment.

Set them to an empty COR group for testing purposes.

MitelInMyBlood has a good checklist above.


When testing, if it still fails, you need to know if you are getting to the other system or being restricted locally.

Turn on the CCS Trace Enable Continuous on the far system and see if the call is getting there.

Don't forget to CCS Trace disable

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

CCS Trace is a GREAT tool!! We've been using it for at least 10 years, poss. longer. Seems someone in PS once let a copy of the training docs slip away ;-)

Fortunately someone saw a need to document it for the 3300, but it works equally well in the 2K at least back to LW29, possibly as far back as the old black boxes. (I forget now when we first saw it) The trainer was Larry Arnold which certainly goes back a ways.

 

[Mitelpassion]

Lundah, I don't quite agree. Access Denied in my opinion means there is either a barring issue or the COS option Public Network Access via DPNSS is not set to yes. The latter should be the case on both trunks and devices.
I've found that the phone displays "Call barred" if the call is rejected by the Telco for some reason.

MiteGuy, best way to test and see if it's a barring issue is if you delete all your entries in the COR group form. Make a note before you do though so you can put them back. If your call succeeds then you need to investigate where the barring is happening. Also make sure about the COS option for Public Access via DPNSS is Yes on all devices and trunks involved.

My guess is this COS option is not set. Good luck

 

[TheMitelGuy]

Solution: DPNSS on the remote IP sets (the sets making the call).

I could not go for help anywhere else - so I appreciate your help.