Where's Waldo? Or More Like What is Using a VDN!!!

[jmbailey]

Ok, this is a strange one.

We have a VDN (86500) that routes calls to 1 of 3 skills. You call it, it works great. However, it isn't supposed to exist!!! And, to top it off, calls are going to the VDN (about 6-10 per month). We'd like to remove it, but......

No matter what we look at and where we search, we can't find anything that is routing calls to the VDN. We have absolutely no idea how calls are getting to it!!! List Usage shows only the VDN. No stations are forwarded to it. No Inc-Trunk is routed to it. No Cover Path is using it. It isn't in UNI. Checking call accounting, no station or auto attendant is dialing the number.

WTH?!?!?!?!? Is there any other way to find out what in the CM is routing calls to the VDN? We are at a total loss.

Thanks!

 

[montyzummer]

Any reporting or CDR collector will give you this info , are you sure you dont have a ddi that ends in 86500 and the incoming treatment table is just routing the call based on what is received.
The other thing to do is name it mystery vdn and when somebody sees that on the phone get them to ask the caller what number they dialed at least then you can look into that

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[Stinney]

You checked all of the inc-call-handling-trmt for each trunk group?

- Stinney
"Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est"

"To know where to find anything is, after all, the greatest part of education"

 

[Stinney]

Also make sure something isn't call forwarded to it: list call-forwarding

- Stinney
"Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est"

"To know where to find anything is, after all, the greatest part of education"

 

[jmbailey]

Yep. Nothing in eCAS Call Accounting. Nothing in trunk treatment. Nothing in call forwarding.

 

[cgogan13]

It could be as simple as someone or some group uses it to transfer calls to, ask your users.

 

[montyzummer]

try a list usage extension 86500 may be that you have a route to step in a vector that the vdn exists in

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[BIS]

list usage digit-string will tell you if it is defined in a variable - you could have route-to V1 somewhere in a vector.

 

[jmbailey]

Tried all list usages, double and triple checked all inc-call-treatments, double checked call accounting, triple checked call recording system, verified no vectors using it, no cover paths, etc.

AAAARRRGGGGHHHHHHH!!!!!!!!!! Something is going to give here soon, either me or the CM!!! One of us is going down!!!

 

[cgogan13]

Did you ask your users if anyone uses that VDN to transfer calls into the queue?

 

[BIS]

Perhaps its coming from an external application like an IVR? You might have a vector collecting digits and route-to digits, but the digits themselves are coming from the IVR so you would never find them in CM

 

[smokinjoe2938]

point the vdn to a new vector that will route the caller to your extension, maybe then you can figure the puzzle out.

 

[jmbailey]

cgogan13......we have over 2500 employees in 25+ offices and we do about 200,000 calls in and out a day. None of these guys pay that close of attention!

smokinjoe......yep, that is what we did this morning. Guess we'll wait and see what happens!!!


Thanks everyone!!!

 

[montyzummer]

Have you checked your system variables , not vdn and do you understand how to decipher them , some can be quite clever and tricky.

Just bear in mind if you have a ddi that matches the vdn number there is possibly no entry in the treatment table , have you called your line providers and checked you dont own this number as a ddi?

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[jmbailey]

monty......yep, chacked all the variables we could find. There is a possibility of only one number that could come into us that would translate to the 86500, but checking this morning, that number doesn't belong to us and goes to another company. All our other inbound number that comes in are all 10 digits and get stripped in such a way that 86500 couldn't occur (at least that is what we are seeing at the moment.).

Thanks!

 

[montyzummer]

ok try this on page2(i think) of change mst enter the vdn number in both the called and calling number on the isdn digits field.

MST does not have to be on for this so bear with me .

then do list trace tac 1234/d (obviously 1234 is an example) then ring in on every tac you have does not matter what number you call in on just make sure its definatly calling each tac individually

so example
list trace tac 1234/d
list trace tac 1235/d
list trace tac 1236/d

Do this until you have called in on every tac on the system what this does is only report an output if the number on the mst screen is detected in your case 86500 so that would be the number in the mst section idsn field , try that for each tac and if it exists you only get info on that call nothing else , granted a lot of testing but a sure fire way to detect where its coming from , i would test the theory on your cell number first put that in the mst section called number and prove it works by tracing the tac with the method i describe and watch only your mobile number call leg show..... then off you go test test test.

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[montyzummer]

oh you can also repeat this on vdn instead of tac .... keep us posted im intreagued

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[jmbailey]

Hmmm....cool......just found something to do this weekend!!!

thanks for the tip and I'll let you know what happens!!!

 

[montyzummer]

no probs i work for stars and beer if it works........ hope it does

APSS (SME)
ACSS (SME)
ACIS (UC)