Caller ID on inbound calls through AA

[blantonlewis]

I have two incoming line groups set up. One group routes to the main hunt group, answered by the receptionist. The other has a destination of VM:backdoor which obviously dumps them in our 'backdoor' automated attendant so that people can go straight to someone's extension, etc.

We get CLID info on calls coming through the main hunt group.

Anyway, I've confirmed w/ a butt set that I'm getting CLID on the backdoor lines also but when the AA transfers the call it shows as ??.

I wondered if one issue was that the AA picks up ASAP, ie it doesn't wait for rings. Thoughts, anyone?

 

[IPGuru]

Have you got CLI detection enabled for the lines, if not the IPO will ingnore it even if sent

 

[blantonlewis]

The lines (like the other terminal group) are set as Loop start ICLID.

 

[Telecomboy]

The system will need 2-rings before it captures the caller id information. So, if you have it immediately picking up with no rings, chances are the system hasn't had time to gather the caller id information.

 

[Telecomboy]

You can set-up the system to wait 2-rings before picking up, but I am not sure how your system is set-up and without complete knowledge I am afraid I might worsen the situation instead of help it.

 

[magix2kewl]

If you have the lines configured correctly when you run monitor and a call comes in for the "backdoor" you should see the statement INCOMING CALL GUARD. Otherwise the lines are still set to loopstart and it will answer before the caller ID signal.

 

[paul3461000]

I had the same problem. I found that when AA was doing a [Transfer] that the CLI information was lost.

Use an [Assisted Transfer] Instead.
On the [Specific] tab put $CLI in the "Source of call" field.

 

[socalsteve]

Telecomboy has the correct answer as far as i'm concerned you need 2 rings from most providers in the U.S. to pass the caller id on loopstart analog lines.

 

[IPGuru]

IP does require 2 rings for CLI detection, but it does not atempt to route the call untill this has been recieved so it should not be causing the problem

try routing this line direct to an extn to see if you are still lossing cli, if so then your CLI type has been incorectly set on the line

 

[blantonlewis]

Turns out that this was also a grounding issue (for whatever reason). See [thread940-1232167]