LightGuy48
IS-IT--Management
We have a DID coming into our system via PRI that we cannot seem to figure out how it is working and we all seem to be stumped.
Basically the last four of the DID is 0023 and I have confirmed on several occasions with the service provider that they are in fact sending 0023.
When you go to the attendant console when someone calls the number you get a= xxx-xxx-xxxx (the caller's CID info).
However, normally when you call one of our main numbers you get the 'coverage path' message as the incoming calls are going through a vector for proper direction of the call depending on the time of day and day of week.
There is no VDN of 0023 and it is not even valid since 0 is used to the attendant inside the building per our dial numbering plan.
My next thought was maybe 0023 is not defined anywhere in our system so it automatically goes to the attendant, so to test that theory I went in and under each trunk group I set the incoming call handling to tie 4 0023 4 5100 but this still did not produce the desired result.
Is there something about 0023 (leading 0) that is causing odd behavior? Or could 0023 still be defined elsewhere in our system? It's not a station, VDN, or a DID translation in a trunk group.
Basically the last four of the DID is 0023 and I have confirmed on several occasions with the service provider that they are in fact sending 0023.
When you go to the attendant console when someone calls the number you get a= xxx-xxx-xxxx (the caller's CID info).
However, normally when you call one of our main numbers you get the 'coverage path' message as the incoming calls are going through a vector for proper direction of the call depending on the time of day and day of week.
There is no VDN of 0023 and it is not even valid since 0 is used to the attendant inside the building per our dial numbering plan.
My next thought was maybe 0023 is not defined anywhere in our system so it automatically goes to the attendant, so to test that theory I went in and under each trunk group I set the incoming call handling to tie 4 0023 4 5100 but this still did not produce the desired result.
Is there something about 0023 (leading 0) that is causing odd behavior? Or could 0023 still be defined elsewhere in our system? It's not a station, VDN, or a DID translation in a trunk group.