D14128.02—NOVEMBER 2008
33
Codec C90
System Integrator Guide
Contents
Introduction
Getting Started
Interfaces
About the API
xConfiguration
xCommand
xStatus
Cameras
Appendices
Contact us
About the API
TANDBERG API
Basic Principles
The heart of the API is the TANDBERG API-
Engine. This is where all information is stored and
processed.
The API-engine can be accessed by an easy-to-
use Command Line Interface called XACLI using
RS-232, Telnet or SSH, or by the TANDBERG XML
API Service (TXAS) over HTTP/HTTPS.
Working with the API-engine is very similar to
working with catalogues and files on a computer.
All information is stored in a hierarchic tree
structure which is accessible from different
interfaces.
When accessing the API-engine using XACLI
•
(RS-232, Telnet or SSH), the information is
formatted in a proprietary Command Line style
or in XML formatting.
When accessing the API-engine using the TXAS
•
interface (HTTP/HTTPS), XML formatting is
supported.
This is similar to viewing files on a computer.
Accessing catalogues on a Windows computer
using the Command Prompt gives a different view
than using Windows Explorer, but the information
is the same.
About Telnet
Telnet is disabled by default. Before connecting to
the codec using Telnet you will need to enable the
interface via either RS-232 or SSH.
The following command can be set from the
Administrator settings menu or from the API
command interface:
xConfiguration NetworkServices
•
Telnet Mode: On
The TANDBERG API-Engine
The TANDBERG API-Engine is optimized for easy, yet advanced, machine-machine interaction between a
TANDBERG system and an external control application.
The main features can be summarized to:
Structuring of information
•
Addressing using XPath (XML Path Language) or TANDBERG SimplePath
•
Feedback
•
Structuring of Information
An application programming interface (API) can be seen as a gate where information
is exchanged between two systems – a control application and a target system.
The control application transmits instructions to the target system, while the target system supplies
information about how these instructions are executed, in addition to other system related information.
Consequently, the exchange of information can be divided into:
Information flowing from target. This we call
1.
READ
information (
R
). The (
R
) should not be confused with
the (
r
) used to indicate required parameters in the Commands tables.
Information flowing to target. This we call
2.
WRITE
information (
W
).
API-Engine
RS-232
cable
Main types of information
If we look at the TANDBERG systems we can
identify three main types of information
READ
•
information (
R
)
WRITE
•
information (
W
)
READ/WRITE
•
information (
RW
)
(R) READ
information. This is Status Information
about the system and system processes, i.e.
information generated by the system.
Typical examples include: status about ongoing
calls, network status, conference status etc. All
status information is structured in a hierarchy,
making up a database constantly being updated by
the system to reflect process changes.
(W) WRITE
information. This is Command
information the user/control application supply to
initiate an action.
Typical examples include: instructing the system
to place a call, assigning floor to a specific site,
disconnecting a call etc.
A command is usually followed by a set of
parameters to specify how the given action is to be
executed.
(RW) READ/WRITE
information. This is
Configuration Information defining system settings.
This information can both be supplied and read
by the user/control application. Typical examples
include: default call rate, baud rate of a serial port,
enabling/disabling of various features etc.
All configuration information is structured in a
hierarchy making up a database of system settings.
But for the Configuration information, the data in
the database can only be updated by the user/
control application.
XACLI
(XML)
TXAS
(XML)
HTTP/
HTTPS
Telnet/SSH
via LAN
