Cisco TelePresence Server API 4.0：远程管理与本地操作模式指南

需积分: 10 164 浏览量更新于2024-07-22 收藏 999KB PDF 举报

Cisco TelePresence Server API 4.0 是一个产品编程参考指南，适用于Cisco TelePresence Server的第4.0版本（2.8）。这份文档详细介绍了两种主要操作模式下的API功能：灵活操作模式（remotely managed）和独立操作模式（locally managed）。在灵活操作模式下，第1部分着重描述了当系统设置为远程管理时可用的API。这种模式下，管理员可以通过用户界面和在线帮助文档所描述的接口进行远程操控。API在此模式下支持的功能包括但不限于系统状态查询、配置管理、会话控制以及与远程用户的交互，旨在提供高度的可扩展性和远程管理便利性。另一方面，独立操作模式（Part 2，从第107页开始）针对的是本地管理，即当系统被设置为本地操控时适用的API。在这种情况下，管理员更直接地管理和维护服务器，可能涉及到对硬件的直接访问和对设备性能的实时监控。 "system.info"方法中的"operationMode"参数用于获取当前的工作模式，这对于开发者在编写代码时确定应调用哪个API至关重要。通过理解和利用这些API，开发人员可以构建与Cisco TelePresence Server无缝集成的应用程序，无论是处理日常运维任务还是实现高级自动化流程。 Cisco TelePresence Server API 4.0提供了强大的工具集，让管理员和开发者能够优化会议体验、管理多用户环境、以及确保系统的高效运行。它不仅提升了系统的易用性和可靠性，还促进了与其他IT系统的集成，增强了整体通信和协作解决方案的能力。理解并掌握Cisco TelePresence Server API 4.0对于提升工作效率，实现远程或本地管理策略，以及创建定制化的解决方案都至关重要。这份指南是开发人员和系统管理员不可或缺的参考资料。

Media credits Media tokens

48 0 to 48

315 49 to 315

630 49 to 630

840 631 to 840

1260 841 to 1260

2520 1261 to 2520

3780 2521 to 3780

5040 3781 to 5040

7560 5041 to 7560

10080 7561 to 10080

Table 5: Media credits to media tokens mapping

If media credit values supplied to API methods do not match any of the values in the "Media credits" column

in the previous table, the value is rounded down to the next level. Supplying media credit values less than 48

allocates 0 credits.

Every participant must have enough credits to use the tokens configured for that participant. API methods fail

if this requirement is not met. This applies to media credit values rounded down as described previously.

Participant calls are rejected if there are insufficient credits when connecting the call to the conference.

Media reservation

Reserved media resources are tokens and credits that have been assigned for exclusive use by a participant.

Reservation guarantees that if an endpoint connection succeeds, media resources required to service the

connection exist.

Note:The token requirements for a call cannot be known prior to instantiation of the call, so no checks are

made on flex.participant.create or flex.participant.modify to determine if the call will have

adequate resources. The client is therefore responsible for ensuring that the call has adequate resources.

Enumeration

This API supports incremental enumeration of objects such as conferences and participants. The following

methods are typically associated with complete enumeration of a type of object:

n flex.object.enumerate

n flex.object.deletions.enumerate

Both methods use cookies to determine what content needs to be returned. To start the enumeration, the

methods should be invoked without supplying a cookie. To continue the enumeration, the methods should be

invoked with the cookie returned by the previous invocation.

Cisco TelePresence Server API 4.0 Product Programming Reference Guide Page 16 of 172

Part 1:Flexible operation mode

Both methods return the boolean parameter moreAvailable. If the value of this parameter is true, more

data is available.

For information on how you can use incremental enumeration to optimize resource usage, see

flex.participant.media.enumerate [p.75].

The .enumerate methods

The .enumerate methods are intended for enumeration of live objects and return lists of object that are new

or have been revised.

To use the .enumerate methods:

n On the first invocation, do not present a cookie. Information is returned on all live objects.

n On subsequent invocations, present a cookie. Information is returned on live objects that have changed or

have been added since the previous invocation as indicated by the cookie.

The .enumerate methods may fail with Fault 102: 'cookie is invalid or expired' if the

enumeration cannot be completed; that is, if all changes or additions that occurred since the last invocation

cannot be listed. In such cases, restart both live and deletions enumerations, discarding the previous state.

The .deletions.enumerate methods

The .deletions.enumerate methods are intended for enumeration of objects that have been destroyed.

They return lists of object IDs that have been deleted since the last invocation as indicated by the cookie.

To use the .deletions.enumerate methods:

n On the first invocation, do not present a cookie, No IDs are returned for the first invocation.

n On subsequent invocations, present a cookie. IDs of objects that have been deleted since the previous

invocation of the method are returned.

The deletions.enumerate methods may fail with Fault 102: 'cookie is invalid or

expired' if the enumeration cannot be completed; that is, if all deletions that occurred since the last

invocation cannot be listed. In such cases, restart both live and deletions enumerations, discarding the

previous state.

Enumeration method invocation

Typically, the enumeration methods should be invoked in response to feedback notification of an event. If the

methods are invoked and no changes have occurred (since the last invocation as determined by the cookie),

empty lists will be returned.

For example, to maintain a list of information about live conferences:

1. Invoke flex.conference.deletions.enumerate [p.53] with no parameters other than the Authentication

[p.116] parameters, and store the cookie string parameter returned as the deletionscookie.

2. Invoke flex.conference.enumerate [p.54] with no parameters other than authentication parameters.

3. Go to step 5.

4. Invoke flex.conference.enumerate [p.54] with the cookie parameter set to the liveobjectscookie.

5. Store the cookie string parameter returned as the liveobjectscookie.

6. Process the list of conferences returned.

Cisco TelePresence Server API 4.0 Product Programming Reference Guide Page 17 of 172

Part 1:Flexible operation mode

7. If moreAvailable is true, repeat from step 4.

8. Go to step 13.

9. Invoke flex.conference.deletions.enumerate [p.53] with the cookie parameter set to the deletionscookie

(see above and also below).

10. Store the cookie parameter returned as the deletionscookie.

11. Process the conferenceIDs array.

12. If moreAvailable is true, repeat from step 9.

13. Wait for feedback notification.

14. In the event of a conference change or addition, go to step 4.

15. In the event of a conference deletion, go to step 9.

In the algorithm above, at the start of the enumeration, flex.conference.deletions.enumerate [p.53] is invoked

before flex.conference.enumerate [p.54]. This ensures that the deletion of any conference returned by

flex.conference.enumerate [p.54] will be returned by flex.conference.deletions.enumerate [p.53] when it

occurs.

It is also possible that flex.conference.deletions.enumerate [p.53] will return the IDs of conferences which

have not been returned by flex.conference.enumerate [p.54]. This can happen when a conference is created

and destroyed before flex.conference.enumerate [p.54] is invoked or the enumeration has not proceeded far

enough to return the conference ID.

Participants and participant media resources can be enumerated in a similar way using the following

methods:

n flex.participant.enumerate [p.73] and/or flex.participant.media.enumerate [p.75]

n flex.participant.deletions.enumerate [p.72]

Feedback events and enumeration

Feedback events are generated to aid incremental enumeration of conferences and participants. See

Feedback events [p.20] for more information.

For conferences:

n When a conference is created, modified or its state changes, the flexConferenceEnum event is

generated. Invoke flex.conference.enumerate [p.54] to retrieve information for newly added or modified

conferences. The flexConferenceEnum event is only generated for those modifications or state

changes that affect data returned by flex.conference.enumerate [p.54].

n When a conference is destroyed, the flexConferenceDeletionsEnum event is generated. Invoke

flex.conference.deletions.enumerate [p.53] to identify which conferences have been destroyed.

Similarly for participants:

n When a participant is created, modified or its state changes, the flexParticipantEnum event is

generated. Invoke flex.participant.enumerate [p.73] to retrieve information for newly added or modified

participants. The flexParticipantEnum event is only generated for those modifications or state

changes that affect the data returned by the flex.participant.enumerate [p.73] method.

n When a participant is created or its media resource state changes, the flexParticipantMediaEnum

event is generated. Invoke flex.participant.media.enumerate [p.75] to retrieve participant media

information. The flexParticipantMediaEnum event is only generated for those modifications or state

changes that affect the data returned by the flex.participant.media.enumerate [p.75] method.

Cisco TelePresence Server API 4.0 Product Programming Reference Guide Page 18 of 172

Part 1:Flexible operation mode

n When a participant is destroyed, the flexParticipantDeletionsEnum event is generated. Invoke

flex.participant.deletions.enumerate [p.72] to identify which participants have been destroyed.

DTMF

The set of valid characters for DTMF is:

*#0123456789ABCD,

The comma character is used to insert delay. Each comma denotes a two-second delay.

Commands that take DTMFstring parameters will accept any non-DTMFASCIIcharacters in the string but

the TelePresence Server will ignore them; it processes the string until it reaches the end, sending only the

tones for characters within the set *#0123456789ABCD and pausing the tone sequence by two seconds for

each comma.

The TelePresence Server returns a fault if there are non-ASCIIcharacters in the string.

Feedback receivers

The APIallows you to register your application as a feedback receiver. This means that the application does

not have to constantly poll the device if it wants to monitor activity. By using feedback events, you can avoid

imposing the high loads that polling can cause especially when there are multiple API users.

The device publishes events when they occur. If the device knows that your application is listening for these

events, it will send XML-RPCmessages to your application's interface when the events occur.

Note:The TelePresence Server expects your application to provide at least an HTTP 200 OK status

header. The TelePresence Server logs a warning event if it cannot be sure your application received the

feedback message.

n Use feedbackReceiver.configure [p.45] to register a receiver to listen for one or more Feedback events

[p.20].

n Use feedbackReceiver.query [p.46] to return a list of receivers that are configured on the device.

n Use feedbackReceiver.reconfigure [p.47] to change the configuration of an existing feedback receiver.

n Use feedbackReceiver.remove [p.47] to remove an existing feedback receiver.

n Use feedbackReceiver.status [p.47] to display the status of a specific feedback receiver, and all the

events to which it is subscribed.

After registering as a feedback receiver, the application will receive feedback messages on the specified

interface.

Feedback messages

The feedback messages follow the format used by the device for XML-RPC responses.

The messages contain two parameters:

n sourceIdentifier is a string that identifies the device, which may have been set by

feedbackReceiver.configure or feedbackReceiver.reconfigure. If it has not been set it will

be the device's MACaddress.

n events is an array of strings that contain the names of the feedback events that have occurred.

Cisco TelePresence Server API 4.0 Product Programming Reference Guide Page 19 of 172

Part 1:Flexible operation mode

剩余171页未读，继续阅读

老白分享

粉丝: 1
资源: 4

Cisco TelePresence Server API 4.0：远程管理与本地操作模式指南

telepresence:Cisco TelePresence Server 8710 API 模拟器

Cisco TelePresence系统中文使用手册

Networkers2009：BRKVID-2304 - Cisco TelePresence Solution Architecture for the Enterprise

Cisco TelePresence SX20 使用手册：Vue.js API 呼叫指南

Cisco TelePresence系统中文使用指南

Cisco TelePresence SX20 使用与安全指南

Cisco TelePresence 企业解决方案架构探索

Cisco TelePresence SX20遥控器详解与功能指南

Cisco TelePresence SX20 使用手册：故障排查与安全指南

Cisco TelePresence SX20 使用指南：摄像机与系统信息设置

最新资源