Auto Attendant on our main line number 2

[supportpbx]

Hi and thank you in advance for any help on the issue that I am having.

It appears that some of the calls coming into our main-line is not being routed to our Auto Attendant. The first call always seems to route to it correctly but then the second calls do not route to Auto Attendant. It just keeps on ringing.

Also, at times, third calls seems to route to the Auto Attendant.

Thank you!

 

[GHTROUT]

You can keep that as a Phantom - less complicated than ACD.

It just occurred to me to look at the obvious

You know that TRK156 20 0 2 0 you keep getting? Is that by chance one of the TNs in the Trunk Route having problems? If it is, then you might want to verify there is dial tone and you can get a call on it. Check the RJ21X for the trunk number.

If that leads nowhere, this still sounds like a bad trunk, based on your most recent description of the problem. How about trying a LD36 LDIC on the route having the problem. See if one of the trunks isn't registering calls.



~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

Thank you. I ran the ldic on the route where the error message was being received. This is also the same route, where I did a call trace from Auto Attendant to my extenstion was verified to.

When I ran the ldic, it seems that it is saying that the route is not an incomin trunk (my records from existing doc. shows it as out going trunk)... Please see below for ldic on route 8.

>ld 36

.ldic 0 8
NO IC TRKS
.


*** Below is the call trace I've done from my cell phone to our main line then transferred to my desk extension.

>ld 80
TRA000
.trac 0 XXXX (my extension)

ACTIVE TN 006 0 09 06
ORIG 020 0 02 00 COT RMBR 8 1 <-- ( trunk Route 8 )
TERM DN XXXX
TDTN 16 SLOT 6 PTY SLOT 6
DIAL DN XXXX (my extension)
MAIN_PM RING AUX_PM
TALKSLOT ORIG 7 TERM 7 JUNCTOR ORIG0 TERM0
EES_DATA:
NONE
QUEU CAD
CALL ID 0 6515


*** I've also ran 'trk' from my Maintenance Set to verify the dial tone on the TN below. It showed the following error message. Maybe it is an outbound/inbound trunk.

.TRK 20 0 2 0
.
TRK006 ( Unit requested or all trunks busy)


*** So I've manually disu and enlu the trunk and verified that it was idle afterwards. See below for output.

.stat 20 0 2 0
BUSY

.disu 20 0 2 0

.enlu 20 0 2 0

.stat 20 0 2 0
IDLE



*** Then I went back into my Maintenance Set and confirmed that it had a dial tone on the TN. See below for the output.

.TRK 20 0 2 0
DN?
.


Thank you for your help once again...

 

[GHTROUT]

Hmm. See your post from [12 Jan 09 19:58] You indicated you determined the route that the lost calls come in on in that post.

If that route is "8" and you get the message ".ldic 0 8 NO IC TRKS" then you should change the RDB's "ICOG" prompt to "IAO"

You can mark a trunk route as "OGT" (Outgoing Only) but still recieve calls... I suspect you are getting incoming calls on a route 8 and it is set for OGT, which blocks you from doing an LDIC command.

There is no risk to setting ICOG to IAO. And then you'll be able to do LDIC. I can't remember if it accumulates daily or real time, but either way you need to find out.


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[GHTROUT]

If all else fails...and as long as we promise to post the final resolution and no money changes hands, I don't feel it is against the rules to suggest "you know how to reach me"


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[TimAbney]

This sounds like a problem with the second trunk in a group not actually routing the call to you pbx. You should check with the vendor and ensure how the trunks are set up from the CO. If it is consistently the second call that does not terminate it should be easy to isolate the second trunk in their hunt group.

 

[GHTROUT]

I think much of it is the thrill of the hunt and learning how one can diagnose issues like this from their desk

I know, the goal is to restore service, not drag out a repair. But an opportunity like this does not come along that often. Most of the time, things just work.


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

Changing the ICOG prompt to IAO worked like a charm. I was then able to print out the ldic of ROUT 8 on LD 36. The report shows that the trunks are being utilized everyday. Please see print out below for reference.

Thank you for all your help, really... I'll keep working on it for now. Once again, this posting has been a really awesome learning session!

.ldic 0 8
TN 020 0 02 00 : 0 DAY(S)
TN 007 0 10 00 : 0 DAY(S)
TN 024 0 01 04 : 0 DAY(S)
TN 005 0 02 00 : 0 DAY(S)
TN 024 0 00 01 : 0 DAY(S)
TN 018 0 02 00 : 0 DAY(S)
TN 008 0 01 02 : 0 DAY(S)
TN 019 0 02 00 : 0 DAY(S)
TN 008 0 00 00 : 0 DAY(S)
TN 008 0 00 04 : 0 DAY(S)
TN 020 0 02 02 : 0 DAY(S)
TN 020 0 02 01 : 0 DAY(S)
TN 004 0 02 01 : 0 DAY(S)
TN 024 0 02 00 : 0 DAY(S)
TN 005 0 02 01 : 0 DAY(S)
TN 024 0 03 01 : 0 DAY(S)
TN 018 0 02 01 : 0 DAY(S)
TN 004 0 04 03 : 0 DAY(S)
TN 008 0 02 02 : 0 DAY(S)
TN 020 0 02 03 : 0 DAY(S)

 

[GHTROUT]

Well, not so fast... it hasn't been more than zero days yet

Come tommorow, things will start to accumulate. You might want to add LD36 into your Midnight DROL

LD 15
REQ CHG
TYPE OVLY
hit return until the following prompt:
DROL (enter "36" at DROL) then return to the end





~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

I see : )

Below is the LDIC from today for your reference. Looking at the output below, can I confirm that there was a incoming call on this route? At least on TN 20 0 2 0?

>ld 36
TRK000
.ldic 0 8
TN 020 0 02 00 : 0 DAY(S)
TN 007 0 10 00 : 1 DAY(S)
TN 024 0 01 04 : 1 DAY(S)
TN 005 0 02 00 : 1 DAY(S)
TN 024 0 00 01 : 1 DAY(S)
TN 018 0 02 00 : 1 DAY(S)
TN 008 0 01 02 : 1 DAY(S)
TN 019 0 02 00 : 1 DAY(S)
TN 008 0 00 00 : 1 DAY(S)
TN 008 0 00 04 : 1 DAY(S)
TN 020 0 02 02 : 1 DAY(S)
TN 020 0 02 01 : 1 DAY(S)
TN 004 0 02 01 : 1 DAY(S)
TN 024 0 02 00 : 1 DAY(S)
TN 005 0 02 01 : 1 DAY(S)
TN 024 0 03 01 : 1 DAY(S)
TN 018 0 02 01 : 1 DAY(S)
TN 004 0 04 03 : 1 DAY(S)
TN 008 0 02 02 : 1 DAY(S)
TN 020 0 02 03 : 1 DAY(S)
.
TRK000

***Also I ran OVLY command on LD 15 and received the following error message, 'SCH0099 OVLY?'

It states that XXX (OVLY) is an invalid response. System does not recognize XXX. See below for reference.

Thank you.

>ld 15
CDB000
MEM AVAIL: (U/P): 8069595 USED U P: 2322152 77628 TOT: 10469375
DISK SPACE NEEDED: 130 KBYTES
2MB BACKUP DISKETTE(S) NEEDED: 1 (PROJECTED LD43 - BKO)
REQ: chg
TYPE: ovly

SCH0099 OVLY?

 

[GHTROUT]

20-0-2-0 has taken a call, but no other trunks have.

Are you certain Route 8 is the route that the ring-no-answer is occuring on?

See your post from [12 Jan 09 19:58] You indicated you determined the route (using TRAC) that the lost calls come in on in that post. You didn't confirm one way or the other it was Route 8 though.

Don't worry about OVLY - the trunk call counters are working. You're system is old enough that OVLY can't be reached the short way. You'd have to enter TYPE CDB.


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

Thank you.

Here is how I have determined the incoming route of our main line number. I made a call to our main line from my cell which was pick-up by our Auto Attendant. From there, I had the call transferred to ext. XXXX. As the call was being transferred, I ran a trace on that extenstion XXXX. I guess this is not really the call that keeps on ringing since it was actually answered by Auto Attendant. However it should be the route that our main line comes in on.

When I carried out the call trace once again today, I found that it came in on a different TN. I must have made mistake when I ran the call trace originally. Below is what I found. Thank you.

>ld 80
TRA000

** First Call Trace **
.trac 0 XXXX (interal extension)

ACTIVE TN 006 0 09 06
ORIG 024 0 11 03 15 TRN
TERM DN XXXX (internal extension)
TDTN 16 SLOT 13 PTY SLOT 11
DIAL DN XXXX (internal extension)
MAIN_PM RING AUX_PM
TALKSLOT ORIG 10 TERM 10 JUNCTOR ORIG0 TERM0
EES_DATA:
NONE
QUEU CAD
CALL ID 0 1895



**Second Call Trace**
.trac 0 XXXX (internal extension)

ACTIVE TN 006 0 09 06
ORIG 008 0 11 08 15 TRN
TERM DN XXXX (internal extension)
TDTN 16 SLOT 17 PTY SLOT 13
DIAL DN XXXX (internal extension)
MAIN_PM RING AUX_PM
TALKSLOT ORIG 17 TERM 17 JUNCTOR ORIG0 TERM0
EES_DATA:
NONE
QUEU CAD
CALL ID 0 1883


***below are the print out of the two ORIG TNs.

DES OCTEL1
TN 024 0 11 03
TYPE 2616
CDEN 8D
CUST 0
AOM 0
FDN
TGAR 0
LDN NO
NCOS 0
SGRP 0
RNPG 0
SCI 0
SSU
XLST
CLS UNR FBD WTA LPR MTD FND HTD ADD HFD
MWD LMPN RMMD SMWD AAD IMD XHD IRD NID OLD VCE DRG1
POD DSX VMD CMSD CCSD SWD LND CNDA
CFTD SFD DDV CNID CDCA MSID DAPA BFED RCBD
ICDD CDMD MCTD CLBD AUTU
GPUD DPUD DNDA CFXD ARHD CNTD CLTD ASCD
CPFA CPTA ABDD CFHD FICD NAID BUZZ AHD
DDGA NAMA
USRD ULAD RTDD RBDD RBHD PGND OCBD FLXD FTTU
CPND_LANG ENG
HUNT
PLEV 02
SPID NONE
AST
IAPG 0
AACS NO
ITNA NO
DGRP
PRI 01
DNDR 0
KEY 00 ACD 4700 0 8065
AGN
01 SCN 8062 0 MARP
CPND
NAME Octel Port 4E
XPLN 13
DISPLAY_FMT FIRST,LAST
02
03
04
05
06 MSB
07
08
09
10
11
12
13
14
15 TRN
DATE 29 MAY 2004


DES OCTEL1
TN 008 0 11 08
TYPE 2616
CDEN 8D
CUST 0
AOM 0
FDN
TGAR 0
LDN NO
NCOS 0
SGRP 0
RNPG 0
SCI 0
SSU
XLST
CLS UNR FBD WTA LPR MTD FND HTD ADD HFD
MWD LMPN RMMD SMWD AAD IMD XHD IRD NID OLD VCE DRG1
POD DSX VMD CMSD CCSD SWD LND CNDD
CFTD SFD DDV CNID CDCA MSID DAPA BFED RCBD
ICDD CDMD MCTD CLBD AUTU
GPUD DPUD DNDD CFXD ARHD CNTD CLTD ASCD
CPFA CPTA ABDD CFHD FICD NAID BUZZ AHD
DDGA NAMA
USRD ULAD RTDD RBDD RBHD PGND OCBD FLXD FTTU
CPND_LANG ENG
HUNT
PLEV 02
SPID NONE
AST
IAPG 0
AACS NO
ITNA NO
DGRP
PRI 01
DNDR 0
KEY 00 ACD 4700 0 8035
AGN
01 SCN 8036 0 MARP
CPND
NAME OCTEL 1F
XPLN 8
DISPLAY_FMT FIRST,LAST
02
03
04
05
06 MSB
07
08
09
10
11
12
13
14
15 TRN
DATE 3 JUN 2004

 

[supportpbx]

I'm wondering if I did the call trace correctly. I am also wondering if the 'ORIG 024 0 11 03 15 TRN' and the 'ORIG 008 0 11 08 15 TRN' are just the calls traced from Octel (Auto Attendant)...

Since the inbound calls to our main line have already successfully reached the Octel (hince the transfer menu option from our AutoAttendant), do you think the Call Trace I ran was just tracing the transferring of the calls from Octel and not from where the calls came in on originally (from out side)?

 

[GHTROUT]

You want to trace an "established call" where you dialed your extension in the AutoAttn from a cell phone call. That is the only way we can determine the trunk route that the call is coming in on.

Your TRAC does not show any trunks.

See 14 Jan 09 16:07


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

I see!!! This time, I made sure that I actually receive the transferred call on my station, before I ran the trace of my cell phone calls.

Below is the output and it does confirm that the calls are coming in on ROUT. I traced 3 calls and they all came in on a same TN in ROUT 8. Please see below for the output.

>ld 80
TRA000
.trac 0 XXXX

ACTIVE TN 006 0 09 06
ORIG 020 0 02 00 COT RMBR 8 1
TERM 006 0 09 06 0 SCR MARP 0 XXXX 2616
DIAL DN XXXX
MAIN_PM ESTD
TALKSLOT ORIG 17 TERM 17
EES_DATA:
NONE
QUEU NONE
CALL ID 0 1397


.trac 0 XXXX

ACTIVE TN 006 0 09 06
ORIG 020 0 02 00 COT RMBR 8 1
TERM 006 0 09 06 0 SCR MARP 0 XXXX 2616
DIAL DN XXXX
MAIN_PM ESTD
TALKSLOT ORIG 18 TERM 18
EES_DATA:
NONE
QUEU NONE
CALL ID 0 1398


.
TRK156 20 0 2 0
trac 0 XXXX

ACTIVE TN 006 0 09 06
ORIG 020 0 02 00 COT RMBR 8 1
TERM 006 0 09 06 0 SCR MARP 0 XXXX 2616
DIAL DN XXXX
MAIN_PM ESTD
TALKSLOT ORIG 15 TERM 17
EES_DATA:
NONE
QUEU NONE
CALL ID 0 1381

 

[supportpbx]

Here is also another finding. I ran a call trace of the 3rd call to our main line (made 3 calls consecutively). First call was pickup by Auto Attendant, second call just kept rining, the third call was also pickup by Auto Attendant. I then traced the third call and confirmed that it also come in on via ROUT 8.

I also ran ldic on the ROUT 8 and saw that TN that was traced (for the third call) showed that it did indeed received the call.

Please see below for print out.



.trac 0 XXXX


ACTIVE TN 006 0 09 06
ORIG 005 0 02 00 COT RMBR 8 4
TERM 006 0 09 06 0 SCR MARP 0 XXXX 2616
DIAL DN XXXX
MAIN_PM ESTD
TALKSLOT ORIG 5 TERM 5
EES_DATA:
NONE
QUEU NONE
CALL ID 0 1352


** LDIC of ROUT 8 **
>ld 36
TRK000
.ldic 0 8
TN 020 0 02 00 : 0 DAY(S) (first calls came in here)
TN 007 0 10 00 : 1 DAY(S)
TN 024 0 01 04 : 1 DAY(S)
TN 005 0 02 00 : 0 DAY(S) (third call. It was 1 before)
TN 024 0 00 01 : 1 DAY(S)
TN 018 0 02 00 : 1 DAY(S)
TN 008 0 01 02 : 1 DAY(S)
TN 019 0 02 00 : 1 DAY(S)
TN 008 0 00 00 : 1 DAY(S)
TN 008 0 00 04 : 1 DAY(S)
TN 020 0 02 02 : 1 DAY(S)
TN 020 0 02 01 : 1 DAY(S)
TN 004 0 02 01 : 1 DAY(S)
TN 024 0 02 00 : 1 DAY(S)
TN 005 0 02 01 : 1 DAY(S)
TN 024 0 03 01 : 1 DAY(S)
TN 018 0 02 01 : 1 DAY(S)
TN 004 0 04 03 : 1 DAY(S)
TN 008 0 02 02 : 1 DAY(S)
TN 020 0 02 03 : 1 DAY(S)

 

[supportpbx]

Perhap one of the trunk in the ROUT 8 (where the second calls come in) is bad? If so what can I do at this point?
Thank you.

 

[GHTROUT]

I'm still surprised the LDIC isn't showing more calls. But you know it is probably the first few, being TN 007 0 10 00 : 1 DAY(S) or TN 024 0 01 04 : 1 DAY(S)

What I would do at this point is go to the phone room and rig a pair of wires to a phone (or better yet, use a butt-set) and identify each of those TNs/trunks has dial tone and can ring into you. The one other poster "TimAbney" pretty much said it the way it is.


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

Sure. I used a Maintenance Set feature from my phone and did a trk to TN 7 0 10 0 and had no dial tone... I check the wire and it looked fine and shows idle in the Print TN output.

Can I assume that the issue maybe with the carrier and that they may need to come out to fix this particular trunk?

Thank you. I hope this is the problem and that we've located with your help.

 

[GHTROUT]

Yes! There's the culprit. What you should do is trace the wire from the TN 7 0 10 0 and see if it is just broken - or if it makes it to the phone company connection. If you are not in a position to get your hands on the cross-connect wire, meet the phone tech in the phone room and plead with them to see if it makes it from the RJ21X (known as the point of demarcation - or "demarc") to the phone system. They will probably help you out.

But "technically", all they have to do is provide dial tone to the demarc - then you're on your own.


~~~
[small]GHTROUT.com | Get the Input/Output Manuals | Tek-Tips FAQs | Recent Replies[/small]

 

[supportpbx]

Thank you so much for all your help! Really, this has been a big learning curve for me. Thank you once again.

I will look into the issue and will be sure to post the result.

Thank you.