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.

 

[rejackson]

My PRIs are public-ntwrk so I dont know how the tie works on a PRI. Could you show us the inc call handling and include some of the entries that are working?

 

[LightGuy48]

Another note, I went into cha dialplan and tried to change 0 from attd to blank or extension and the system would not accept the change, it's like something has 0 locked as the attendant function no matter what.

I've got a call into our telco service provider to see how hard it would be to change the translation from 0023 to 2323 to see if it fixes the issue.

It just really seems to me that our system for what ever reason is intercepting the leading 0 coming from the PRI and is immediately processing the 0 to attendant instead of looking at the incoming call handling treatment table

 

[vulcanccit]

Lightguy, since you and I are working on this internally, do you have any other numbers that are working via the inc-call-handling? if so maybe list trace tac those and compare the two traces... I can compare the Reno list trace too and see how it compares. Also did you try 10 digits on your absorbe replace? I know we did 4 and 7, but how about 10?

 

[vulcanccit]

here is the Reno trace for 0220 (last 4 of the number somewhat similar to what you need to do on yours):

15:26:05 Calling party trunk-group 1 member 1 cid 0xfc
15:26:05 Calling Number & Name 6023815733 NO-CPName
15:26:05 active trunk-group 1 member 1 cid 0xfc
15:26:05 dial 5223
15:26:05 ring station 5223 cid 0xfc
15:26:05 G711MU ssff ps:20 rn:1/1 10.2.51.82:2532 10.2.51.33:2076
15:26:05 xoip: fax:Relay modemff tty:US 10.2.51.33:2076 uid:0x94f
15:26:08 idle trunk-group 1 member 1 cid 0xfc

 

[LightGuy48]

Here is one that works

time data

17:38:42 Calling party trunk-group 1 member 69 cid 0x2cb
17:38:42 Calling Number & Name 9183446084 NO-CPName
17:38:42 active trunk-group 1 member 69 cid 0x2cb
17:38:42 dial 5146
17:38:42 ring station 5146 cid 0x2cb
17:38:48 active station 5146 cid 0x2cb
17:38:50 idle trunk-group 1 member 69 cid 0x2cb


I've tried 10 digits as well, no change

 

[vulcanccit]

I looked at his system and udp is not defined in dialplan. 0 is attd for 1 digit dialed. list extension-type show no extensions below 3000

A question for this thread..

is it possible for them to send zero digits?

above someone said

"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."

so there is no UDP so it would default to the System-Parameters-Features, which is indeed attd

If that happens does it say IC= when the call is displayed?

I just think they are not sending any digits or the number arriving is not what we think it is like the telco is call forwarding the number to something else maybe?

here is his system features

FEATURE-RELATED SYSTEM PARAMETERS
Self Station Display Enabled? n
Trunk-to-Trunk Transfer: none
Automatic Callback - No Answer Timeout Interval (rings): 3
Call Park Timeout Interval (minutes): 10
Off-Premises Tone Detect Timeout Interval (seconds): 20
AAR/ARS Dial Tone Required? y
Music/Tone on Hold: music Port: 01B0912
Music (or Silence) on Transferred Trunk Calls? all
DID/Tie/ISDN Intercept Treatment: attd
Messaging Service Adjunct (MSA) Connected? n
Internal Auto-Answer of Attd-Extended/Transferred Calls: transferred
Automatic Circuit Assurance (ACA) Enabled? n




Abbreviated Dial Programming by Assigned Lists? n
Auto Abbreviated/Delayed Transition Interval (rings): 3
Protocol for Caller ID Analog Terminals: Bellcore
Display Calling Number for Room to Room Caller ID Calls? n

and his

system parameters coverage forwarding

CALL COVERAGE/FORWARDING PARAMETERS

Local Cvg Subsequent Redirection/CFWD No Ans Interval (rings): 4
Off-Net Cvg Subsequent Redirection/CFWD No Ans Interval (rings): 2
Coverage - Caller Response Interval (seconds): 4
Threshold for Blocking Off-Net Redirection of Incoming Trunk Calls: 1

COVERAGE
Keep Held SBA at Coverage Point? y
External Coverage Treatment for Transferred Incoming Trunk Calls? n
Immediate Redirection on Receipt of PROGRESS Inband Information? n
Maintain SBA At Principal? y

Station Hunt Before Coverage? n

FORWARDING
Call Forward Override? n
Coverage After Forwarding? y

 

[LightGuy48]

Except that there is no IC when this occurs and on a couple of occasions I have tested on DID's within our DID block that have no VDN or station associated with it, immediately it shows up at the attendant with an IC suffix as configured.

When calling the 0023 DID there is no IC suffix at the attendant console.

If the system is treating it as intercepted it is not displaying as such.

 

[LightGuy48]

Another note, went into sys-param feat and re-directed intercept from attd to 5702 which is an announcement and it did not re-direct DID 0023 to the announcment.

 

[LightGuy48]

Here is some more information as we've been testing after hours...

I went into dialplan this evening and removed the attd assignment from the 0 digit, it did not fix the issue to my hypothesis of the dialplan somehow interferring was not correct.

Something else is translating 0023 to send to 0

 

[1a22ip]

Jumping in late here but could it be negative programming. Because there is no extension or endpoint assigned to 0023 the system will terminate the call to the Attendant. From a post above: FEATURE-RELATED SYSTEM PARAMETERS

DID/Tie/ISDN Intercept Treatment: attd

Just the old phone guy thinking again. To prove this change the field attd. This field will take attd or an announcement station.

Hope this helps

1a2 to ip I seen it all

 

[vulcanccit]

1a22ip we tried that as well, we put in another extension instead of attd and it still rang the attendant console.

 

[1a22ip]

OK Sorry I am now officially stumped.


Thanks
ED

1a2 to ip I seen it all

 

[letman2]

in my dial plan I have dial string 0 twice. once with total length of 1 and once with total lengh of 5. both of these are set as extensions. The single digit one waits for more digits and after a period of time when none are received completes the call to the operator. If I dial all five digits it will complete the call to the 5 digit extension.

 

[LightGuy48]

Thanks, but when I tried removing attd from the digit 0 in the dialplan it did not fix the problem as I expected it to.
Also, I tried changing digit 0 in the dialplan to misc and it also did not fix the problem

So it appears that dialplan digit 0 is not the culprit in this problem.

 

[slammer33]

i thing with PRI you can absorb all the digits and replace them with any digits, so the vendor is sending 0023 yet the definity is taking these digits and replace with others, i forgot with the commad that you can do this may be AAR, try to dig that way and see if there is such a set up

 

[LightGuy48]

Thanks for the tip, there was a 0 defined in AAR and I removed it but it didn't help. I went and checked system-parameters and found AAR/ARS is disabled for incoming DID calls so the AAR digit conversion wasn't even enabled.

Please keep the ideas coming!

 

[Duaneness]

Following up on Letman2's suggestion - can you add 0 to the dialplan as a 4-digit extension and test what happens?

 

[LightGuy48]

Duaneness we tried 0 without the 'attd' definition and it didn't seem to change the issue, I'm not sure how making it an extension would make difference.

We did get our provider to change the translation of the DID from 0023 to 2323 and now everything is operating normally so there is something about the leading 0 causing the issue.

I think we're just going to abandon the problem and any leading zero's in the future. We were on a tight timetable to get this fixed so we had to go with the workaround via the translation change.