These steps describe the IP phone agent login process:
The agent selects the services button on the 7940 or 7960 telephone and selects the IP phone service.
The browser in the IP phone sends an HTTP request to the Tomcat web server that is identical to the URL the system administrator has configured on the Cisco CallManager for the service. This URL identifies the Tomcat web server (port = 6293) and the ipphone/jsp/sciphonexml/IPAgentInitial.jsp page, which is case sensitive .
The Tomcat web server receives the HTTP request and sends it to the IP phone service (which is a web application that runs in Tomcat) for further program logic processing.
The IP phone service communicates with the IP phone agent server through Java ORB. The IP phone agent server Interoperable Object Reference (IOR) is saved in a file, which is decided through the pathname that resides in the registry. By using the IP address of the IP phone (collected by the IP phone service), the IP phone agent server decides which page the IP phone service should generate for display on the IP phone.
Using the IP address argument, the IP phone agent server checks whether the agent is already in the list of agents logged in through the IP phone service. If the agent is logged in, IP Phone Service returns the states screen (step 18) or otherwise returns a login screen.
For the login screen, the IP phone service operates to create the XML document "CiscoIP Phone Tags" and responds to the Tomcat web server.
The Tomcat web server responds with a request back to the telephone browser.
The phone browser displays the page to the agent.
The agent enters his or her desktop identification, password, and IP Contact Center (IPCC) Express extension and selects submit.
The phone browser sends a request to the Tomcat web server with the login identity, password, extension, and the identity of the login .jsp page.
The Tomcat web server receives the request and passes it to the IP phone service along with the login information.
The IP Phone Service issues a request to the IP phone agent server for login service, passing the arguments from step 10.
The IP phone agent server checks whether there are any more licenses available. The IP phone agent licenses are kept in memory and do not use the semaphore files like Cisco Agent Desktop (CAD). If there are licenses available, the IP phone agent server increments the memory count to indicate that another instance of IP phone agent has started and continues with the login process. If the maximum number of licenses has been reached, the IP phone agent server returns an error indicating that to the IP phone service .
The IP phone agent server retrieves the agent's profile from Lightweight Directory Access Protocol (LDAP), based on the agent input. If the directory does not hold a corresponding entry, the IP phone agent server uses default information. Otherwise the IP phone agent server continues with the login process.
The IP phone agent server logs the agent into the IP contact center through the Computer Telephony Integration (CTI) server (IPCC Express).
Note: The IP phone agent server performs the login for the agent with respect to the telephone extension that the agent entered into the phone browser window. The IP phone agent server makes no attempt to determine whether the agent actually entered the information at the telephone with that extension. The password used is the one entered by the agent, not the one in LDAP.
If the agent was successfully logged into the CTI server, the IP phone agent server sends a message to the chat server, indicating that the agent has just logged in and is in a Not Ready state and returns success to the IP phone service. Otherwise, the IP phone agent server returns the error to the IP phone service.
If an error is returned to the IP phone service at any point, the error page with the error description is displayed to the agent.
If the login is successful, the IP phone service asks the IP phone agent server for the agent's current state. It then asks for the states menu for the specified state. It uses this information to construct the states menu XML document and pass it to the Tomcat web server with the IP address and port of the telephone browser.
The Tomcat web server returns the page to the telephone browser.
I'd like to figure out if it's possible to get CER to acknowledge the existence of a VG320 as an analog phone. In our environment we have alarms and dialers that rely on analog lines provided by gateways that call 911. The problem is that because all emer...
From CSR compatibility matrix I do not see ATA 186 since version 10.5, but I understand is supported on ver 10,x 11.1 & 12.0.My question is ATA 186 is supported on CUCM ver 12.5?If so, do you have a link to validate it? Thanks in advancedEnrique
I have a UCCE v12.5 environment and am looking at the Call_Type_Interval table (CTI) trying to understand some of the fields that customer is reporting on.A question was raised as to why the "CallsOfferred" field doesn't match (or is lower) than the "Rout...