NARS/BARS restrictions between primary IAO T1 and a Tie T1

[wilcom]

I just programmed a tie [DID] route to connect the existing Opt11 with a Shoretel system.

Internal calls to/from the shoretel phones go back and forth no problem. External calls to/from the shoretel phones are intercepted by the Opt11 attendant.

The two systems are connected locally via a cross-over cable, so I have some flexibility with the configuration.

I have tested several different arrangemnts with the NCOS, TARG's, and FRL's, but no luck.

Any wisdom would be MOST appreciated.

Thank you.
-Seth

 

[johnpoole]

External calls to/from the shoretel phones are intercepted by the Opt11 attendant.

external calls? is this a did to the 11 you want to send to the shoretel? if so check a couple of things.. of course the targ of the two routes can not match, i always x1 that prompt. and the ncos of the inbound route has to be high enough to make the call.. i usually mark the tie as internal but that is not the block inmost cases.. did call hits the 11, you get digits from the provider, your using dsc's to send it to the shoretel? trad that inbound trunk in 80. post that and we may see something

john poole
bellsouth business
columbia,sc

 

[wilcom]

John, Thanks for the post.

I'm defining "external call" as: a call comming in over the inbound route in the Opt11, and handed off to the tie route that points to the Shoretel. The hand-off is the point of failure. Dialing 4 digits internally back and forth between the systems works fine. The DID's are set up as DSC's out of the Opt11.

The routing appears to be fine...It's the restrictions that are blocking the calls. I x'd the TARG on the tie route, the inbound route is still set to 1.

I traced an internal and external call as shown below. Example 1 completes succesfully, 4 digit internal dialing over route 20 [TIE] on loop 2.

Example 2 was intercepted by the Attendant after comming in on the inbound route 7.

Let me know if you see anything.

EXAMPLE 1:
.trac 0 3299

ACTIVE TN 022 0 00 15
ORIG 022 0 00 15 0 SCR MARP 0 3299 2616
TERM 002 05 DID RMBR 20 5
DIAL DN 3119
MAIN_PM DIAL AUX_PM COMPLETE
TALKSLOT ORIG 8 TERM 8
EES_DATA:
NONE
QUEU NONE
CALL ID 0 468

AUX NARS

---- ISDN PRA CALL (TERM) ----
CALL REF # = 69
BEARER CAP = VOICE
HLC =
CALL STATE = 4 DELIVERY
CALLING NO = 4085483299
CALLED NO = 3119

PDCA 1 PAD 0 6 PCML MU MU


EXAMPLE 2:
.trac 0 3299

ACTIVE TN 022 0 00 15
ORIG 022 0 00 15 0 SCR MARP 0 3299 2616
TERM 008 19 DID RMBR 7 42
DIAL DN 95483119
MAIN_PM ESTD
TALKSLOT ORIG 20 TERM 20
EES_DATA:
NONE
QUEU NONE
CALL ID 0 551


---- ISDN PRA CALL (TERM) ----
CALL REF # = 22378
BEARER CAP = VOICE
HLC =
CALL STATE = 10 ACTIVE
CALLING NO = 5483299
CALLED NO = 5483119

PDCA 1 PAD 0 6 PCML MU MU

 

[GHTROUT]

You're tracing the call you are placing...'example 1' is a usefull TRAC because it shows you conecting to the Route that links to the Shoretel.

'Example 2' is not an informative TRAC because it only shows you dialing from your phone to the public network. It does not show what is happening from the public network back into your DIDs.

The Route that inbound callers arrive at your Option 11 contains trunk TNs that have an NCOS value. The LD14 NCOS value on those inbound trunks should be Zero and the TGAR should be Zero

Then, the LD86 Route List for the LD87 Steering Codes should have an FRL of Zero in each ENTR/ROUT.

That completely eliminates NARS/BARS from being the restricting factor.

If that still results in failure, look at the LD21 TYPE INT.

Those prompts folloowed by four values (ATN, OVF, etc.) define where a variety of restricted or misdialed calls land. Rathr than go into detail on that, there are two other options: Out the DID TRKs and the DID route that connects you to the Shoretel and rebuild it as TIE ~or~ Out the Option11's DID TRKs and RDB that external callers arrive via... and rebuild it as TYPE CSA.



~

http://www.GHTROUT.com/