CCMA Real Time Display Error

[symposium21]

Hi All,

Can somebody help regarding Real Time Display, for some reason during peak hour the RTD Tabular Display was not displaying the Agent status correctly but rather it displayed an asterisk(*)or UNKNOWN on the status. I didn't know if it is a license issue or something. We're transmiting data in unicast. Is there a license limitation on accessing RTD on CCMA? How can I know my RTD utilization? Is there an issue in transmitting unicast simultaneously?

Thanks in advance..

 

[sandyml]

No, not a license limitation. It is more likely some network congestion causing timeouts. You might consider increasing your TTL on the CCMS server. This is found in RTD Multicast Configuration - even if you use unicast to the desktops, you are still multicast from CCMS to CCMA.

To your question about the number of unicast transmissions, that is an engineering capacity issue for your CCMA server and your network. In the CCMA, you will specify the number of simultaneous unicast sessions allowed. Any more than that, and users will not be able to pull up a realtime screen at all (it won't show just ***, you won't get any names, etc.). Increasing that number adds load to your CCMA server and on the network. If you are getting network timeouts now, that wouldn't be the best thing to do.

 

[symposium21]

Thanks sandyml, Avaya was working on this issue but suddenly instead of resolving the issue. The issue get worst, we can't able open the real time display anymore.

It say "The system could not retrieve any data from the server because either the server connection is down, or there are currently no skillsets logged in. If the server connection is working, then try launching the display again later.
Transmit Mode = Unicast"

Their recommendation was to rebuild the server, can you help me to troubleshoot the issue.

Can you help me to check if the CCMS transmit data?

I want to see if there's no problem with the server. Even if I lanch the WebClient on CCMA i still get the same error. Please advice if you need anything from my end.

Thanks

 

[picklemogg]

Hi- back in the day of classic client the * thing or repeat information was common and usually required a PEP to resolve. I haven't seen the issue in CCMA, but you may need to have to update SU/PEPs on the CCMA/CCMS server. I know- I hate that answer as well. Maybe you are running a close to up to date SU?

So you need to determine what Avaya did to make the problem worse? I doubt you need to rebuild.

Can you perform other functions from CCMA- historical reporting and contact center management for example?

Does the multicast send IP on CCMS server match the multicast recieve on CCMA server?

There is a multicast test tool on the CCMA server that you can use to test that data is making it to the CCMA server from CCMS.

Are all services started on CCMS including SDP?

Did you restart RTR service on CCMA?

Did you restart the servers?

There are a few things to try.

Todd

 

[Utreg]

From the Nortel website, a tool to test multicast:
"Test and validate unicast and multicast configurations on your network with Multicast Hammer: an easy to use, Java-based testing tool."

http://www.nortel.com/corporate/nortel_on_nortel/multicast_hammer.html

 

[karenbiel]

I have seen this happen on site where there a a high number of partitions and high traffic. There is a setting on the CCMA server, in the same area where the Output Rate(rate the multicast data is sent from the CCMA server to the Supervisor's PCs) and the Transform Rate(time it takes to transfrom the multicast data from the CCMS server to a format for the Supervisor's PCs) are set , it is the OAM Timeout value. Default is 10,000. It is recommended that you increase this value in increments of 10,000 until you have no further issues.

 

[DancingDave]

We had an issue with agent RTDs as we had up to 900 concurrently logged in at one time. The multicast packets were too big (the packlet contains ALL data, even if you're only viewing a subset of it) and our WAN provider was dropping them. As a result, we saw the asterisks, frozen screens and 'not able to retrieve...' messages too, though not in Head Office where the servers are and where we don't police this

There were no issues early in the day when we only had a few agents logged in.

The fix was to get the WAN supplier to make changes so that these packets weren't dropped (increased he size threshold I think)

DD