D14642.02—MAY 2010
10
TANDBERG Codec C60 and Codec C40
API Guide
Contents Introduction About the API xConfiguration xCommand xStatus Appendices Contact us
www.tandberg.com
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:
1. Structuring of information
2. Addressing using XPath (XML Path
Language) or TANDBERG SimplePath
3. Feedback
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
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:
1. Information flowing from target. This we call
READ information (R). The (R) should not
be confused with the (r) used to indicate
required parameters in the Commands
tables.
2. Information flowing to target. This we call
WRITE information (W).