Unused DID #'s do not ring to Attendant 2

[jasidija]

I was under the impression that if, in the INT_DATA block, the 'Call To Vacant Number' was set to ATN, that unassigned DID's would ring to the Attendant.

Not working for me.

Here is my INT_DATA block:
TYPE INT_DATA
CUST 00
ACCD OVF OVF OVF ATN
CTVN OVF OVF OVF ATN <=========
MBNR OVF OVF OVF ATN
CTRC OVF NAP OVF NAP
CLDN NAP OVF NAP NAP
NINV OVF OVF OVF ATN
NITR OVF OVF OVF ATN
NRES OVF OVF OVF ATN
NBLK OVF OVF OVF ATN
RCLE ATN OVF ATN ATN
CONG OVF
DLT OVF
LLT OVF
DNDT BSY

If I program ZZZZ on a TN and call # XXX-YYY-ZZZZ - it rings on that TN.
If I remove the appearance of ZZZZ from the TN and call XXX-YYY-ZZZZ - it rings busy.

How can I get this unused number to route to my attendant console - so the receptionist can answer - instead of having it ring busy??

 

[GHTROUT]

First lets make sure you are testing XXX-YYY-ZZZZ from, say, a cell phone, just to make sure your BARS LDID isn't forcing the test call to re-route internally.

Next, lets make sure the route that XXX-YYY-ZZZZ comes in on is classified as "DID" and not "TIE".

Then let's make sure your Attendant is really a M2250? Just want to make sure we are both speaking the same terms.

Let us know if you make headway... this is an unusual issue.


[&copy;] GHTROUT.com [&hArr;] Resources for Nortel Meridian/CS1000 System Administrators - You Can Hire Me Too

 

[jasidija]

Appreciate the clarification.

I'm not only dialing from off-net, I'm dialing from another state - and we don't have any TIE trunks between sites.

The Attendant is really a M2250. This is definite.

And yes, the number is fed from the Telco into the site in question via a DID route.

It's not service affecting, but just wondered if there was maybe another parameter/config option that might be overriding the CTVN setting.

Thanks, GH - Have a Merry Christmas

 

[Reusser]

set up a new RLI with LTER=yes and DMI that deletes 4 (assuming you receive 4 digits from telco and inserts 0 for attendant.

then in ld 15/net_data - at prompt VNR say Yes, RLI enter new RLI, FLen=4 (again if reveive 4 digits), CDPL=4 (again if reveive 4 digits).

 

[GHTROUT]

Reusser: Is that something new? A new requirement?

[&copy;] GHTROUT.com [&hArr;] Resources for Nortel Meridian/CS1000 System Administrators - You Can Hire Me Too

 

[Reusser]

not new - not sure why this users CTVN is not intercepting to attendant - could be that cs1000 is responding to incoming DCH setup as "unequipted number" and telco is terminating instead of call being allowed to intercept.

VNR would just be a workaround.

 

[johnpoole]

CDPL,LOCL.. if you set those to your dn length, then answer vnr yes, then enter the dn or route you want them routed to, that should work (cdb)

CTVN RAN RAN RAN RAN (rdr data)
RANR 85
we send calls to a ran route on vacant numbers,,, if you really want just did's to go to your 2250's.. put them in an idc table

john poole
bellsouth business
columbia,sc

 

[jasidija]

Wow - got the big guns looking at this one - thank you for each of your input!

So... a little more on discovery:

It appears that the NET data block overrides the INT data block config.

In other words - when the VNR in the NET data block is set to YES (and configured), the call no longer pays attention to the CVTN setting in the INT data block.

My VNR was set to YES, so my first look at CVTN was not indicative of what was really steering the call.

Furthermore - why was I getting a busy?
Because the RLI defined within the VNR is a RLI which routes the call to a virtual trunk route - to our NRS.

The NRS sees the 4 digits, associates it with the site it just came from, and tries to send it back... = loop = busy.

At least that's what I'm concluding.

So, I set the VNR to NO and now calls to unused DN's ring to attendant.

HOWEVER - now 4 digit dialing between sites does not work. So I set the VNR back to 'YES' with the original config.

I think somebody used the VNR to get all unused DN's to the NRS - instead of using/building CDP in the PBX.

Guess I can set VNR to NO - after I define remote site extensions in CDP.

Fun times.

Thanks again for each of your help - Have a GREAT New Year!