Cisco Cisco Prime Collaboration Assurance 11.5 ユーザーガイド

See

Start a Troubleshooting Workflow, on page 9

for details on how to start a troubleshooting workflow for conferences

and endpoints.

• When there is a packet loss, jitter, or latency alarm between the two endpoints, the troubleshooting workflow starts if you have

configured for the automatic troubleshooting; when this alarm is cleared, the troubleshooting workflow stops.

• Troubleshooting is supported between two endpoints in both directions. You can select the direction for troubleshooting between

the endpoints, if you are manually starting the troubleshooting workflow.

• Troubleshooting is supported between a video endpoint and SBC. The troubleshooting direction is from a video endpoint to

SBC, and not in the reverse direction.

• Troubleshooting is supported between an endpoint and Cisco TelePresence Server. The troubleshooting direction is from an

endpoint to Cisco TelePresence Server, and not in the reverse direction.

• Troubleshooting is supported between an endpoint and Cisco MSE. The troubleshooting direction is from an endpoint to Cisco

MSE, not in the reverse direction.

• Troubleshooting is supported between an endpoint and Cisco VCS. The troubleshooting direction is from an endpoint to Cisco

VCS and not in the reverse direction.

• If the endpoint is in an Unknown state, you can troubleshoot from a known endpoint to this unknown endpoint. For multipoint

conferences also, you can troubleshoot in the same manner.

• The troubleshooting workflow lasts for a maximum of four hours from the time it is started. If the troubleshooting workflow

does not end within this time, Cisco Prime Collaboration ends the workflow automatically.

• You can have a maximum of 50 concurrent troubleshooting workflows at a time.

If this limit is exceeded, an error message is displayed in the troubleshooting log file.

The following are the key behaviors of the troubleshooting workflow, when scheduled conferences are added to the watch list:

• The automatic troubleshooting workflow starts for all conferences added to the watch list.

• In a multipoint conference, the troubleshooting starts as soon as the endpoints join the conference.

• In a multipoint conference, if a troubleshooting is stopped for an endpoint, the troubleshooting workflow continues for the other

endpoints in the conference. You need to manually start the troubleshooting for this endpoint.

• In a multipoint conference, if an endpoint restarts because of a problem, a new troubleshooting workflow is triggered for this

endpoint after it rejoins the conference. There is no impact on the other endpoints in the conference.

• If a conference is removed from the watch list, the associated troubleshooting workflow stops, provided:

◦There are no packet loss, jitter, or latency alarms triggered for that conference.

◦There are no manually triggered troubleshooting workflows.

• If a troubleshooting workflow is triggered because of a packet loss, jitter, or latency alarm, the troubleshooting workflow stops

when the packet loss, jitter, or latency alarm is cleared, provided:

◦The conference is not added to watch list.

◦There are no manually triggered troubleshooting workflows.

◦The troubleshooting workflow is manually stopped, or the conference ends.