Cisco Acano X-series 開発者ガイド
Cisco Meeting Server Release 2.0 : API Reference Guide
61
Response
elements
elements
Type/Value
Description/Notes
excessiveJitter
String
Present if there is a high level of jitter on one or more of the call leg’s active
media streams
media streams
highRoundTripTime
String
Present if a high round trip time has been detected for one or more of the
call leg’s media streams
call leg’s media streams
Note on alarms:
Call leg alarms provide information that may be useful in raising alarms or troubleshooting issues
after they have occurred but they should not necessarily be treated as if they are alarm
conditions in themselves—unlike system level alarms.
Call leg alarms provide information that may be useful in raising alarms or troubleshooting issues
after they have occurred but they should not necessarily be treated as if they are alarm
conditions in themselves—unlike system level alarms.
A call leg alarm may be triggered by a number of factors, not necessarily a set percentage
packet loss for example. An alarm condition is attached to a call leg when the Meeting Server
believes that the call leg may be being degraded. These "conditions" may include a simple
threshold, but potentially other things too such as a more adaptive threshold and taking other
factors into account. This does not necessarily mean that the user’s experience was poor but it
provides information to troubleshoot in the event that it was. Therefore you could consider
adding filters to this alarm information and deciding when to flag an event as an alarm to the
operator (i.e. setting your own thresholds) and/or storing call leg alarm information alongside
CDRs so that if a user reports a poor quality call you can retrieve this information after the event
to determine what the cause might have been.
packet loss for example. An alarm condition is attached to a call leg when the Meeting Server
believes that the call leg may be being degraded. These "conditions" may include a simple
threshold, but potentially other things too such as a more adaptive threshold and taking other
factors into account. This does not necessarily mean that the user’s experience was poor but it
provides information to troubleshoot in the event that it was. Therefore you could consider
adding filters to this alarm information and deciding when to flag an event as an alarm to the
operator (i.e. setting your own thresholds) and/or storing call leg alarm information alongside
CDRs so that if a user reports a poor quality call you can retrieve this information after the event
to determine what the cause might have been.
8.3.2 Adding and Modifying Call Legs
n
Adding: POST method to a “/calls/<call ID>/callLegs” node. The <call ID> is learnt from a GET
on “/calls” or from a newly created call (see Creating a new call above). If a profile has been
applied to this call leg, it starts with the values set in the profile
on “/calls” or from a newly created call (see Creating a new call above). If a profile has been
applied to this call leg, it starts with the values set in the profile
n
Modifying: PUT method performed on a “/callLegs/<callLeg ID>” node. It makes live, dynamic,
changes to an in-progress connection to a remote party.
changes to an in-progress connection to a remote party.
Note: You cannot modify the remoteParty, bandwidth or confirmation.
Parameters
Type/Value
Description/Notes
remoteParty *
String
For POST only, specifies the call leg’s
address; this could be a SIP URI, a phone
number, or a user JID to invite that user to the
call.
address; this could be a SIP URI, a phone
number, or a user JID to invite that user to the
call.
8 Call Related Methods