Cisco Cisco TelePresence MCU 4510 Developer's Guide
Introduction
Cisco TelePresence MCU API 2.9
Page 6 of 223
Transport protocol
The device implements HTTP/1.1 as defined by
[2]
. It expects to receive communications over
TCP/IP connections to port 80 (default HTTP port) or port 443 (default HTTPS port).
Your application should send HTTP POST messages to the URL defined by path
/RPC2 on the device's
IP address, for example
https://10.0.0.53/RPC2.
You can configure the device to receive HTTP and HTTPS on non-standard TCP port numbers if necessary,
in which case append the non-standard port number to the IP address.
in which case append the non-standard port number to the IP address.
Clustering
From version 4.1 of the MCU software onwards you can configure MCU blades in a cluster in order to
increase the number of HD conference participants. One MCU acts as a master controlling up to two slave
MCUs.
increase the number of HD conference participants. One MCU acts as a master controlling up to two slave
MCUs.
Considering API overhead when writing applications
Every API command that your application sends incurs a processing overhead within the device’s own
application. The exact amount of overhead varies widely with the command type and the parameters sent. It
is important to bear this in mind when designing your application’s architecture and software. If the device
receives a high number of API commands every second, its overall performance could be seriously impaired
– in the same way that it would be if several users accessed it simultaneously via the web interface.
application. The exact amount of overhead varies widely with the command type and the parameters sent. It
is important to bear this in mind when designing your application’s architecture and software. If the device
receives a high number of API commands every second, its overall performance could be seriously impaired
– in the same way that it would be if several users accessed it simultaneously via the web interface.
The current implementation of the MCU API will accept a maximum of four concurrent XML RPC requests
and is limited to a maximum of eight concurrent TCP connections.
and is limited to a maximum of eight concurrent TCP connections.
For this reason, the best architecture is a single server running the API application and sending commands to
the device. If multiple users need to use the application simultaneously, provide a web interface on that
server or write a client that communicates with the server. The server would then manage the clients’
requests and send API commands directly to the device. Implement some form of control in the API
application on your server to prevent the device being overloaded with API commands. This provides much
more control than having the clients send API commands directly and will prevent the device’s performance
being impaired by unmanageable numbers of API requests.
the device. If multiple users need to use the application simultaneously, provide a web interface on that
server or write a client that communicates with the server. The server would then manage the clients’
requests and send API commands directly to the device. Implement some form of control in the API
application on your server to prevent the device being overloaded with API commands. This provides much
more control than having the clients send API commands directly and will prevent the device’s performance
being impaired by unmanageable numbers of API requests.
Furthermore, the API is designed to have as little impact as possible on the network when responding to
requests. The device’s responses do not routinely include data that is not relevant, or empty data structures
where the data is not available. Your application should take responsibility for checking whether the response
includes what you expected, and you should design it to gracefully handle any situations where the device
does not respond with the expected data.
requests. The device’s responses do not routinely include data that is not relevant, or empty data structures
where the data is not available. Your application should take responsibility for checking whether the response
includes what you expected, and you should design it to gracefully handle any situations where the device
does not respond with the expected data.