Attendant Console - Line State Unknown!!! Need Assistance Urgently

[brian-henry]

I was looking around because we are experiencing the problem with our AC showing status unknown for the line state and have been looking into it.

We were @ 3.2(2C) and had upgraded around 1 month ago and I have just now been informed of the problem.

I have checked the ac user ID and password that is the default and even ran the passwordutil and the other one to make sure that the file ACServer.properties contained the correct info. The TSP(current version for Client and server) is setup for ac and its PW and with the sub first and then Pub next. All services are running TCD and CTI, all versions are in sync except for the reporting tool for which I have to do.

We are currently running 3.3(3)sr4, and I am aware of the bug and to move to 4a for the RP.

I ran into this file and was curious of it contents because for the java it points to the wrong place or am i looking at it wrong.

There is NO C:\Program Files\Cisco\CallManagerAttendant(\jre1.4\bin)

There is on the client but not the server or is that where it pulls its app from to run this bat?

set CCMROOT=C:\Program Files\Cisco

set ACROOT=%CCMROOT%\CallManagerAttendant

set JREPATH=%JAVA_HOME%\bin;%ACROOT%\jre1.4\bin

@Echo off

REM

REM Usage:

REM -url <val> : Directory URL, ex: ldap://ldap.cisco.com

REM -searchBase <val> : Search Base, ex: "ou=people, o=cisco.com"

REM -searchFilter <val> : Search Filter def: "(objectClass=inetOrgPerson)"

REM -managerDN <val> : User account to access directory.

REM -managerPW <val> : Password for that account.

REM -department <val> : Directory attribute for department, def: department

REM

REM Save the current path environment variable

set OPATH=%PATH%

REM Setup the various environment variables

set CCMROOT=C:\Program Files\Cisco

set ACROOT=%CCMROOT%\CallManagerAttendant

set JREPATH=%JAVA_HOME%\bin;%ACROOT%\jre1.4\bin

set CLASSPATH=%ACROOT%\lib\ac.jar

set CLASSPATH=%CLASSPATH%;%ACROOT%\lib\ldapbp.jar

set CLASSPATH=%CLASSPATH%;%ACROOT%\lib\log4j.jar

set CLASSPATH=%CLASSPATH%;%ACROOT%\lib\crimson.jar

set CLASSPATH=%CLASSPATH%;%ACROOT%

set PATH=%JREPATH%

cd /d %ACROOT%

REM Start building the userlist

java com.cisco.ac.server.ldap.ACBuildUserList %*

REM Restore the original path variable

set PATH=%OPATH%

The Pilot Point works fine, The hunt group works fine, its just line state.

I also ran the performance monitor on the server and it is 11, which means everything is registered and happy.

I am running out of places to look.

[trailman73]

Is your Cisco Telephony Call Dispatcher service running?

Geoff

[brian-henry]

As stated in the original post both CTI Mnager and TCD services are running.

If you have any other ideas let me know.

I did create myself an AC account and setup the attendant console on my pc, setup the TSP not for the user ID ac but for mine, and then logged into the application.

I can see just about everyone's line state except for a few, that might have thre phones forwarded to VM.

Very weird.

[ROBERT Clark]

Did you upgrade the client versions of AC ?

-Rob

[brian-henry]

Both client and Server are the same. The receptionist got a new machine and its ben that way as from the beggining as far as I am told.

Thanks for your input though.

[christy.kim]

Did you ever this your questions resolved? I am running to the same issue, non of the line information appears for my attendant console.

Thanks,

Christy

[PvanBreda]

Stop and restart the TCD (Cisco Telephony Call Dispatcher Service) on your callmanager server.

If you have a publisher and subscriber do it on both.

[JASON NIELSEN]

Are the numbers Shared line apperances?

[christy.kim]

Kind of . . . we are using 7940 and line one and two are the same ext. but are in different partitions.

[paul.harrison]

Call Manager CTI (3.X) is NOT partition and Calling Search Space aware.

So if you have the same number in different partitions, the line state has no idea which one you want to monitor, so I reckon it is deciding to monitor neither. Try deleting one of the lines to see if this resolves the problem.

Paul

[JASON NIELSEN]

That is correct and why I posed the question. I have delt with this same issue.

[john.nield]

is there any NAT between you AC and CCM? we recently upgraded from 3.1.X to 3.3(3) (WA to AC) and found that the problem was NAT related! line status info status is sent using a separate UDP session and is not understood by the cisco router running NAT between the CCM and AC. this problem could also be ACL related.

thanks

john