DID - can't find?

[LightGuy48]

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.

 

[SF0751]

What do you get with the command "list usa ext 0023"?

Susan
“Before you criticize someone, you should walk a mile in their shoes.
Then, when you criticize them, you are a mile away ...
and you have their shoes.”

 

[LightGuy48]

Extension is invalid due to dialplan

Which per the dialplan 0 is the attd

 

[vulcanccit]

I work with Mr. LightGuy and compared another switch in our company and one of our systems has 0220 and 0229 handled in the Incoming call handling and that works fine.

I keep thinking the phone company is not sending him 4 didgits (we tried 7 too) or when the number is called the phone company is forwarding it somehow to the main number so 0023 is never in play...

 

[LightGuy48]

Is there anyway to view or log the DID information coming into the system via the D channel on the PRI?

Or is there some way to view the call route information / log within the switch?

 

[LightGuy48]

Some more notes, this is a G3 V9 system, I've been playing around with list trace tac and I can see the call coming in and what it shows is dial 0 and then calling attd

I keep wondering if our dial numbering plan may be interferring somehow but I'm going to try turning off the attendant for 0 and set it to extension and see if it works, or is that possibly a bad idea for testing purposes?

 

[AvayaTier3]

If the provider is sending any number of digits that begin with 0 and your dialplan has 0 defined as attd, the rest of the digits will be ignored and the call will always go to the attendant.

Your idea for testing this is a good one. You will just have to give up dial 0 calls to test this.

If this comes in on isdn, you could use incoming call handling treatment for 0023 and delete 4 digits, then insert a valid 4 digit station to send the calls to.
Or you could have your provider change the digits to something that fits your dialplan.

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

35 years Bell, AT&T, Lucent, Avaya
Tier 3 for 25 years and counting

http://bshtele.com

 

[LightGuy48]

I have tried the incoming call handling treatment and it doesn't seem to resolve the issue.

Is there some setting in trunk-group settings that needs to be turned on to enable the incoming call handling treatment translation?

I tried:

tie 4 0023 4 5100 (incoming 4, 0023, del 4, replace with 5100) and no other options enabled and it didn't fix the problem.

 

[LightGuy48]

Ok some more notes, I tried changing the translation on another one of our incoming call treatment lines and it did change so I know it is working.

Is there any kind of trace function that will actually display the DID digits coming from the CO on our PRI?

 

[bparr]

You have to do this from the emulator not GEDI, but you can do a list trace tac X where X is the trunk number (list trunk) the catch, is you will only trace the next call in, so if someone else calls before you, you will have to try again.

 

[AvayaTier3]

put a trunk-id button on the console. Call DID to 0023 and have the attendant use the trunk-id button to identify the incoming trunk-group and member for that call. Then you can change the incoming call handling treatment for the correct trunk-group and route the call somewhere it can be answered without changing your dialplan.

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

35 years Bell, AT&T, Lucent, Avaya
Tier 3 for 25 years and counting

http://bshtele.com

 

[LightGuy48]

I've already done the trunk-id and verified the trunk-group is correct, and the incoming casll handling treatment is correct. It's like either the DID information is not correct or the dialplan is overriding the incoming call handling treatment.

Is there any way to run a trace command that will actually show the DID information coming from the CO?

 

[rejackson]

I guess you are saying that you get 4 digits from the carrier. I would try adding entries for various lengths and see if you get a match.

There are two things, that I know of, that control what happens if there is not a match in the incoming call handling.

First it goes to the uniform dialing plan. The digits can be matched and substituion can take place similar to the inc tru table. If there is no match it goes to the Intercept treatment defined in the system parameters features command. See if that points to the attendant and if it does change it to another extension to see if the call is really falling through both of the table match checks.

 

[LightGuy48]

It's not being intercepted, there is no IC indication at the attendant's console (verified by dialing an undefined DID and it produce the IC indicator), also when running a trace it clearly shows it's dial 0 and transferring to the attendant.

That's what makes me think some how the dialplan is coming into play even though I'm under the impression at the incoming call level it should not even be a factor.

 

[bparr]

Is there any way to run a trace command that will actually show the DID information coming from the CO?"

Try list trace tac, from my above post.

 

[LightGuy48]

Thanks, but but as I stated previously it does not appear to provide that information, I've watched it several times as I've called in and it doesn't seem to provide that information.

 

[98Converter]

As bparr suggested: list tra tac xxx xxx being the tac of the DID trunk group. Call the number and watch it route. Place the trace in the forum, and maybe someone will something...




Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[rejackson]

As bparr suggested: list tra tac xxx xxx being the tac of the DID trunk group. Call the number and watch it route. Place the trace in the forum, and maybe someone will something...


He already said he did that in his 4th post and it says "dial 0"....

It a bugger....

 

[98Converter]

Oops missed that entry:

Is this a US trunk or International trunk? I know in Germany, the digit handling is different... And they actually forward the call within the trunk group on the PBX using overlap/overlap (on page 2).

What if you list trace attendant x - same thing?

Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[LightGuy48]

Here is the trace

time data

16:48:40 Calling party trunk-group 1 member 65 cid 0x15a
16:48:40 Calling Number & Name 9183446084 NO-CPName
16:48:40 active trunk-group 1 member 65 cid 0x15a
16:48:40 dial 0
16:48:40 ring attendant-group 1 cid 0x15a
16:48:48 active attendant 6100 cid 0x15a