TANDBERG Gatekeeper/Border Controller API D14172.01 User manual

TANDBERG
Gatekeeper/Border Controller
API User Guide
D14172.01
July 2008

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 2 of 84
Table of Contents
1The TANDBERG API................................................................................................................. 3
1.1 Introduction to XML..................................................................................................................... 4
1.2 Introduction to XML Path Language (XPath) .............................................................................. 6
1.3 The TANDBERG XML Engine.................................................................................................... 8
1.4 The XML Documents.................................................................................................................. 9
1.5 Introduction to TANDBERG XML API Service (TXAS).............................................................. 14
1.6 Exercises.................................................................................................................................. 19
2The XML-based Advanced Command Line Interface........................................................... 21
2.1 XACLI....................................................................................................................................... 21
2.2 The Status-type root commands – xstatus / xhistory................................................................ 24
2.3 The Configuration-type root commands - xconfiguration........................................................... 26
2.4 The Command-type root commands - xcommand.................................................................... 29
2.5 XML Output - xgetxml............................................................................................................... 32
2.6 Special Commands................................................................................................................... 33
3API - Configurations............................................................................................................... 37
3.1 configuration.xml – xconfiguration ............................................................................................ 37
4API - Commands..................................................................................................................... 48
4.1 command.xml – xcommand...................................................................................................... 48
5API - Status ............................................................................................................................. 60
5.1 status.xml – xstatus.................................................................................................................. 60
5.2 history.xml – xhistory................................................................................................................ 71
5.3 event.xml – xevent.................................................................................................................... 74

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 3 of 84
1 The TANDBERG API
This document is a guide to the API interface of the TANDBERG Gatekeeper and Border Controller
products. All rights reserved. This document contains information that is proprietary to TANDBERG.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form,
or by any means, electronically, mechanically, by photocopying, or otherwise, without the prior written
permission of TANDBERG. Nationally and internationally recognized trademarks and trade names are
the property of their respective holders and are hereby acknowledged.
Disclaimer
The information in this document is furnished for informational purposes only, is subject to change
without prior notice, and should not be construed as a commitment by TANDBERG. The information in
this document is believed to be accurate and reliable; however TANDBERG assumes no responsibility
or liability for any errors or inaccuracies that may appear in this document, nor for any infringements of
patents or other rights of third parties resulting from its use. No license is granted under any patents or
patent rights of TANDBERG.
This document was written by the Research and Development Department of TANDBERG, United
Kingdom. We are committed to maintaining a high level of quality in all our documentation. Towards
this effort, we welcome your comments and suggestions regarding the content and structure of this
document. Please fax or mail your comments and suggestions to the attention of:
Research and Development Department
TANDBERG
Philip Pedersen vei 22
1366 Lysaker
Norway
Tel: [phone]
Fax: [phone]
COPYRIGHT © 2008, TANDBERG

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 4 of 84
1.1 Introduction to XML
XML is a markup language for documents containing structured information.
All information elements in an XML document are marked by a tag and a corresponding end-tag. The
end-tag has the same name as the tag, but is prefixed with a slash ( / ). All tags are put within
angular brackets ( < > ).
Example 1.1
Below is an example of how the configuration for SNMP could be represented using XML.
<Configuration>
<SNMP item="1">
<Mode item="1">On</Mode>
<CommunityName item="1">public</CommunityName>
<SystemContact item="1">Administrator</SystemContact>
<SystemLocation item="1"></SystemLocation>
</SNMP>
</Configuration>
From the tree structure of this example we can see that Mode, CommunityName, SystemContact
and SystemLocation are properties of the SNMP configuration. We can distinguish between
container-elements and value-elements. Container-elements contain one or more sub-elements, while
value-elements contain a value. This is analogous to files and folders on a computer. Container-
elements are folders that can contain sub-folders and files, while value-elements are files containing
data.
In the XML structure for the SNMP configuration we see that the container-element SNMP contains four
sub-elements. All these sub-elements are value-elements, each holding values for the properties:
Mode, CommunityName, SystemContact and SystemLocation.
Example 1.2
In this example we will look at element attributes. Attributes are used to add meta information to an
element. Attributes are placed within the start tag of an element and different attributes are separated
by space.
An XML structure representing the status of a connection to an NTP server is shown below:
<Status>
<NTP item="1" status="Inactive"/>
</Status>
We can see from the status attribute of the NTP element that the NTP connection is Inactive. This
is because it has yet to be configured. There is no further relevant information when the NTP status is
inactive therefore the sub-structure of the NTP element is empty.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 5 of 84
Example 1.3
If we now look at the NTP element once NTP has been correctly configured we see that it now
contains more sub-structure:
<Status>
<NTP item="1" status="Active">
<Address item="1">10.0.0.2</Address>
<Port item="1">123</Port>
<LastUpdate item="1">2008-01-01 12:00:00</LastUpdate>
<LastCorrection item="1">1</LastCorrection>
</NTP>
</Status>
In this example, the attributes are used to provide valuable information in addition to establishing a
dependency to the underlying sub-structure of the element.
Example 1.4
In the above examples, all elements have an attribute named item. This attribute specifies the
instance number of the element. If we examine the DNS configuration for a system which has two
DNS servers configured then the XML structure would look like this:
<Configuration>
<IP item="1">
<DNS item="1">
<Server item="1">
<Address item="1">10.0.0.3</Address>
</Server>
<Server item="2">
<Address item="1">10.0.0.4</Address>
</Server>
<Domain item="1">
<Name item="1">example.com</Name>
</Domain>
</DNS>
</IP>
</Configuration>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 6 of 84
1.2 Introduction to XML Path Language (XPath)
XPath is a comprehensive language to address data in XML documents. It is, however, very simple to
understand the basics. If you are able to specify the path to a file on your computer, you are able to
specify the path to an element in a XML structure.
Example 1.5
Let us go back to the SNMP configuration of Example 1.1:
<Configuration>
<SNMP item="1">
<Mode item="1">On</Mode>
<CommunityName item="1">public</CommunityName>
<SystemContact item="1">Administrator</SystemContact>
<SystemLocation item="1"></SystemLocation>
</SNMP>
</Configuration>
To specify the path to the SNMP element we simply start at the root level and separate the levels in the
tree structure by a slash ( / ):
Configuration/SNMP
The path to the CommunityName element is:
Configuration/SNMP/CommunityName
Example 1.6
To address a specific item of an element, the item number is added within brackets ( [ ] ) after the
element name.
The path to the Address element of Server item 2 in Example 1.4 is:
Configuration/IP/DNS/Server[2]/Address
If the item number is omitted for an element, all items of this element will be addressed. The following
expression addresses the Address element of all DNS servers:
Configuration/IP/DNS/Server/Address

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 7 of 84
Example 1.7
When using XPath it is possible to omit specifying intermediate levels in the address expression. By
using the powerful “double slash" you can address elements without having to specify the complete
path.
To show all the aliases registered on the system, the complete path would be:
Status/Registrations/Registration/Aliases/Alias
Using the “double slash" syntax this can be simplified to:
Status//Alias
Example 1.8
XPath also supports addressing by putting constraints on element attributes. The below expression
will address the Name element of all Failed zones in a system:
Status/Zones/Zone[@status="Failed"]/Name

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 8 of 84
1.3 The TANDBERG XML Engine
The TANDBERG XML engine is optimized for advanced machine-machine interaction between a
TANDBERG system and an external control application. The main features can be summarized as:
•Structuring of information
•Addressing using XPath
•Feedback
1.3.1 Structuring of Information
An application programming interface 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.
Thus, the exchange of information can be divided into:
1. information flowing from target, hereby called read information (r)
2. information flowing to target, hereby called write information (w)
If we now look at the TANDBERG systems we can identify three main types of information, either
being read information (r), write information (w) or read-write information (rw):
1. (r) Read information – Status Information.
Information about the system and system processes, i.e. information generated by the system.
For example: status about registered systems, ongoing calls, network status etc.
All status information is structured in a hierarchy, making up a database constantly being
updated by the system to reflect process changes.
2. (w) Write information – Command Information.
Information supplied by the user to initiate an action.
For example: instructing the system to place a call, disconnect an existing call, remove a
registration etc.
A command is usually followed by a set of parameters to specify how the given action is to be
executed.
3. (rw) Read-Write information – Configuration Information.Information defining system
settings. This information can both be supplied and read by the user. For example: IP settings,
bandwidth settings, 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.
1.3.2 Addressing using XPath
To address information in the hierarchic structure of Status and Configuration information the
TANDBERG systems support abbreviated XML Path Language (XPath). This allows the user/control
application to address everything from a single element of data (for example the source address of a
specific call), to larger parts of the hierarchy (for example all information available for a given call).
The structuring of information together with XPath for addressing makes up powerful features like
searching and setting of multiple instances of a configuration.
1.3.3 Feedback
Feedback is an extremely powerful feature where the TANDBERG system actively returns updated
status and configuration information to the user/control application whenever changes occur. The
user/control application can specify what parts of the status and configuration hierarchies it wants to

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 9 of 84
monitor by using XPath. The user/control application can therefore limit the amount of information it
receives from the target system to only those parts being of interest for the given application.
1.4 The XML Documents
1.4.1 Documents
The XML Data in the TANDBERG systems are divided into three main types of documents. The
division is based on whether the information is Read Information, Write Information or Read-Write
information:
1. Status documents (r): Documents holding all available Status Information in the system.
Supported documents:
a. status.xml
b. history.xml
2. Configuration documents (rw): Documents holding all system configurations.
Supported documents:
a. configuration.xml
3. Command documents (w): Documents defining the supported system commands used to
initiate system processes. This is write data, i.e. the parameter values for a given command are
defined by the user and posted to the system. The posted values will not be returned when
reading the document from the system. Reading a command document from the system returns
descriptions of the supported commands with empty parameter values.
Supported documents:
a. command.xml
4. Meta Documents: Meta documents contain information that can be referenced by other
documents, e.g. value domains of configurations or command parameters. Supported Meta
Documents:
a. valuespace.xml
1.4.2 Status Documents (r)
The Status Documents are characterised by an extensive use of XML attributes. In addition to holding
information, the attributes are used to reflect the structure of the sub-elements, which are dependent
on the state of the system.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 10 of 84
Example 1.9
The element Zone will contain different sub elements depending on the zone status:
<Status>
<Zones item="1">
<Zone item="2" status="Failed">
<Cause item="1">No gatekeeper reachable</Cause>
<Name item="1">MyNeighbor</Name>
<Gatekeeper item="1" status="Failed">
<Cause item="1">DNS Resolution Failed</Cause>
<Address >baddns.example.com</Address>
<Port item="1">1719</Port>
</Gatekeeper>
<Calls item="1"/>
<Bandwidth item="1">
<Total item="1">Unlimited</Total>
<PerCall item="1">Unlimited</PerCall>
<Used item="1">0</Used>
</Bandwidth>
</Zone>
</Zones>
</Status>
<Status>
<Zones item="1">
<Zone item="1" status="Active">
<Name item="1">MyNeighbor</Name>
<Gatekeeper item="1" status="Active">
<Address >10.0.0.10</Address>
<Port item="1">1719</Port>
</Gatekeeper>
<Calls item="1"/>
<Bandwidth item="1">
<Total item="1">Unlimited</Total>
<PerCall item="1">Unlimited</PerCall>
<Used item="1">0</Used>
</Bandwidth>
</Zone>
</Zones>
</Status>
In the above example we see that the Cause element is only present if the zone status is Failed.
1.4.3 Configuration documents (rw)
The structure of the Configuration documents is independent of system state, i.e. the structure will be
constant in time. In addition to holding the values for the various configurations, each configuration
value-element includes an attribute, valueSpaceRef, referencing the value domain for the
configuration.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 11 of 84
Example 1.10
From the XML structure below we see that the Speed element of Ethernet[1] is configured to Auto.
The Speed element references the EthernetSpeed element in the ValueSpace document,
showing the value domain for this configuration.
<Configuration>
<Ethernet item="1">
<Speed item="1" valueSpaceRef="/ValueSpace/EthernetSpeed[@item='1']">
Auto</Speed>
</Ethernet>
</Configuration>
---
<ValueSpace>
<EthernetSpeed item="1" type="Literal">
<Value >Auto</Value>
<Value >10half</Value>
<Value >10full</Value>
<Value >100half</Value>
<Value >100full</Value>
</EthernetSpeed>
</ValueSpace>
To change configurations, the part(s) of the document containing the configurations to be updated
should be posted back to the system with the new values. Posting configuration to the system is
described in section 1.5 Introduction to TANDBERG XML API Service (TXAS).
1.4.4 Command documents (w)
Command documents contain descriptions of the supported commands for the system. A Command
consists of a Command name and a set of Command parameters. The parameter elements have
attributes to denote whether the parameter is optional or required, in addition to referencing the value
domain for the given parameter.
Command parameters do not contain any values when read from the system.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 12 of 84
Example 1.11
The command Dial is defined to take five parameters. Only the callSrc and callDst parameters
are required; this is specified by the attribute required. The value domain for the parameters is
referenced by the attribute valueSpaceRef.
<Command>
<Dial item="1">
<callSrc item="1" required="True"
valueSpaceRef="/ValueSpace/MandatoryAlias[@item='1']"></callSrc>
<callDst item="1" required="True"
valueSpaceRef="/ValueSpace/MandatoryAlias[@item='1']"></callDst>
<Bandwidth item="1" required="False"
valueSpaceRef="/ValueSpace/BandwidthPerCall[@item='1']"></Bandwidth>
<EncryptionMode item="1" required="False"
valueSpaceRef="/ValueSpace/EncryptionModes[@item='1']"> </EncryptionMode>
<EncryptionType item="1" required="False"
valueSpaceRef="/ValueSpace/EncryptionTypesSpace[@item='1']">
</EncryptionType>
</Dial>
</Command>
To issue a command, the command structure is posted back to the system together with values for the
various parameters. Optional parameters can be omitted when posting the structure back to the
system.
Example 1.12
To place a call from Alice to Bob the user can simply post the following XML structure to the system:
<Command>
<Dial item="1">
<callSrc item="1">[email protected]</CallSrc>
<callDst item="1">[email protected]</CallDst>
</Dial>
</Command>
When issuing commands, the system will return an XML structure in response. The response structure
will have the same name as the command issued, but it will be suffixed with Result. All commands
will have an attribute named status, stating whether the command was accepted or not. If a
command is not accepted, the response structure will contain a Cause code. If the command is
accepted, the response structure may contain information relevant for the specific command.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 13 of 84
Example 1.13
The Dial command in the above example may return the following response structure:
<Command>
<DialResult item="1" status="OK">
<callSrc item="1">[email protected]</callSrc>
<callDst item="1">[email protected]</callDst>
<Bandwidth item="1">384</Bandwidth>
<CallSerialNumber item="1">1</CallSerialNumber>
<EncryptionMode item="1">Auto</EncryptionMode>
<EncryptionType item="1">Auto</EncryptionType>
</DialResult>
</Command>
The response structure for the Dial command, DialResult, states that the command was accepted
by the system. In addition to stating that the command was accepted, the Dial command returns the
element CallSerialNumber. This lets the user identify/trace the call in the Status documents
(status.xml and history.xml).
Example 1.14
Below is an example of the Dial command not being accepted by the system because the same alias
has been specified for both the callSrc and callDst:
<Command>
<DialResult item="1" status="Error">
<Cause item="1">89</Cause >
<Description item="1"> callSrc and callDst must have different
aliases</Description>
</DialResult>
</Command>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 14 of 84
1.5 Introduction to TANDBERG XML API Service
(TXAS)
TXAS is a service provided by TANDBERG units for transmitting and receiving information encoded in
XML format.
The API uses HTTP(S) as the transport mechanism and connects to the normal web port (80). TXAS
can be accessed in two ways:
•bare-bone HTTP requests where URLs uniquely identify the request, and
•SOAP, where a single URI is used but the request itself is encoded with XML.
1.5.1 Bare-bone HTTP(S) access
The bare-bone HTTP(S) mode uses a unique URL to identify the specific request. The contents of the
HTTP body will be a XML document (or part of it).
Bare-bone HTTP(S) access is accomplished by passing arguments in the query string (after '?' in a
URI) in a GET request, or using the "application/x-www-form-urlencoded" content-type method of
POSTing form data.
getxml
Request URI: /getxml
Request parameter: location = XPath expression
The getxml request returns an XML document based on the location parameter passed to the request.
The elements (or complete document) matching the expression will be returned.
If an invalid XPath expression is supplied, a <Fault> element with a <XPathError> element will be
returned.
Example 1.15
Using the Unix curl command, the up time of a system can be retrieved from the Status document:
curl –k –u admin:<password> \
https://10.0.0.1/getxml?location=Status/SystemUnit/Uptime
<?xml version="1.0"?>
<Status>
<SystemUnit item="1">
<Uptime item="1">604800</Uptime>
</SystemUnit>
</Status>
formputxml
Request URI: /formputxml
Request parameter: xmldoc = "an XML document of Configuration or a Command"
This is most useful in a POST (to extend character limit of 255 of GET urls). It posts a Configuration or
Command document to set some configuration values or issue a command.

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 15 of 84
Like getxml, it has the data URL form-data encoded with one single parameter. The Content-Type of
the document must be of type “application/x-www-form-urlencoded" and the body must be encoded
accordingly (e.g. first line will be xmldoc=<then the document>).
Example 1.16
Using the Unix curl command, the systems SNMP contact can be set in the Configuration document:
curl –k –u admin:<password> -d \
'<Configuration><SNMP><SystemContact>Alice</SystemContact></SNMP></Configur
ation>' https://10.0.0.1/formputxml
<?xml version="1.0"?>
<Configuration>
<Success/>
</Configuration>
The new configuration value can be confirmed using the getxml request:
curl –k –u admin:<password> \
https://10.0.0.1/getxml?location=Configuration/SNMP/SystemContact
<?xml version="1.0"?>
<Configuration>
<SNMP item="1">
<SystemContact item="1">Alice</SystemContact>
</SNMP>
</Configuration>
Example 1.17
Using the Unix curl command, the dial command can be invoked on the target system to place a call
between Alice and Bob:
curl –k –u admin:<password> -d \
'<Command><Dial><callSrc>Alice</callSrc><callDst>Bob</callDst></Dial></Comm
and>' https://10.0.0.1/formputxml
<?xml version=“1.0"?>
<Command>
<DialResult item="1" status="OK">
<callSrc item="1">Alice</callSrc>
<callDst item="1">Bob</callDst>
<Bandwidth item="1">384</Bandwidth>
<CallSerialNumber item="1">00000000-0000-0000-0000-000000000000
</CallSerialNumber>
<EncryptionMode item="1">Auto</EncryptionMode>
<EncryptionType item="1">Auto</EncryptionType>
</DialResult>
</Command>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 16 of 84
putxml
Request URI: /putxml
Request parameter: HTTP BODY as argument
Putxml is like formputxml, but uses the complete BODY as the argument (i.e. the content of the
xmldoc parameter). The Content-type should be set to either "text/xml", "application/xml" or
"text/plain".
1.5.2 SOAP
The command and configuration interface is also available over SOAP. The syntax for the interface is
specified using the Web Services Description Language (WSDL). The WSDL file is located at the root
of the system’s web server at the URL “/webservices.wsdl": e.g.
http://10.0.0.1/webservices.wsdl
Most programming environments have built in support for developing web service clients or else third
party libraries are available. The following examples use the PHP scripting language to illustrate how
to develop a client web service for the Gatekeeper and Border Controller.
Example 1.18
The example below shows how to reboot the system using the boot command:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$client->Boot();
?>
Example 1.19
The example below shows how to use the dial command which requires parameters to be passed as
part of the operation:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$client->Dial( array('callSrc' => 'Alice', 'callDst' => 'Bob') );
?>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 17 of 84
The SOAP interface has a number of operations for dealing with Status and Configuration:
GetXML
Returns status or configuration information for a specified XPath expression. The returned
value is an XML document.
GetConfiguration
Returns configuration information for a specified XPath expression. The returned value is a
strongly typed SOAP value as defined in the WSDL document.
GetConfigurationXML
Returns configuration information for a specified XPath expression. The returned value is an
XML document.
SetConfiguration
Sets configuration. The configuration parameter is passed as an XML document.
SetConfigurationXML
Sets configuration. The configuration parameter is passed as strongly typed SOAP
parameters as defined in the WSDL document.
Example 1.20
The example below shows how to use GetXML to retrieve information about the system unit from the
status document and extract the up time:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$result = $client->GetXML( array('Location' => '/Status/SystemUnit') );
$xml_result = SimpleXMLElement( $result->GetXMLResult->any );
echo $xml_result->SystemUnit->Uptime;
?>
Example 1.21
The example below shows how to use GetConfigurationXML to retrieve information about the SNMP
configuration and extract the system contact:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$result = $client->GetConfigurationXML( array('Location' => '/SNMP') );
$xml_result = new SimpleXMLElement(
$result->GetConfigurationXMLResult->any );
echo $xml_result->SNMP->SystemContact;
?>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 18 of 84
Example 1.22
The example below performs the same task as Example 1.21 but uses GetConfiguration:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$result = $client->GetConfiguration( array('Location' => '/SNMP') );
echo $result->GetConfigurationResult->Configuration->SNMP->SystemContact;
?>
Example 1.23
The example below shows how to use SetConfigurationXML to modify the SNMP system contact
configuration:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$config_xml = '<Configuration xmlns="http://www.tandberg.no/XML/CUIL/1.0">
<SNMP><SystemContact>Alice</SystemContact></SNMP></Configuration>';
$params = array( 'Document' => array('any' => $config_xml) );
$client->SetConfigurationXML( $params );
?>
Example 1.24
The example below shows performs the same task as Example 1.23 but uses SetConfiguration:
<?php
$client = new SoapClient('http://10.0.0.1/webservices.wsdl',
array('login' => '<username>', 'password' => '<password>'));
$params->Document->Configuration->SNMP->SystemContact = 'Alice';
$client->SetConfiguration( $params );
?>

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 19 of 84
1.6 Exercises
The exercises in this section are based on using a TANDBERG Gatekeeper and Microsoft Internet
Explorer. Some of the examples may however also apply to other systems and other browsers.
NOTE! Replace the IP address 10.0.0.1 in the below examples with the IP address of your system.
Exercise 1
The example in this exercise shows how to read the supported XML documents from the system using
a web browser.
Enter the following address in the browsers address field:
http://10.0.0.1/status.xml
http://10.0.0.1/history.xml
http://10.0.0.1/configuration.xml
http://10.0.0.1/command.xml
http://10.0.0.1/valuespace.xml
Exercise 2
This exercise shows how to use getxml to read the supported XML documents from the system. Enter
the following expressions in the browser’s address field.
(NOTE! The first letter in the document names is uppercase):
http://10.0.0.1/getxml?location=Status
http://10.0.0.1/getxml?location=History
http://10.0.0.1/getxml?location=Configuration
http://10.0.0.1/getxml?location=Command
http://10.0.0.1/getxml?location=ValueSpace
Exercise 3
This exercise shows how to use XPath expressions to read subsets of the XML documents.
http://10.0.0.1/getxml?location=Status/SystemUnit
http://10.0.0.1/getxml?location=Configuration/SNMP/SystemContact
http://10.0.0.1/getxml?location=ValueSpace/SNMPCommunityName[@item='1’]
http://10.0.0.1/getxml?location=Configuration/IP//Address
http://10.0.0.1/getxml?location=Command/Dial

TANDBERG Gatekeeper/Border Controller API User Guide
D14172.01 page 20 of 84
Exercise 4
The address: http://10.0.0.1/xmlput.ssi contains an editor where XML data can be edited and then
posted to the system by pressing the save button. Below are examples of XML structures to be posted
to the system:
<Configuration>
<SNMP>
<SystemContact>Administrator</SystemContact>
</SNMP>
</Configuration>
---
<Configuration>
<SNMP>
<SystemContact>Administrator</SystemContact>
</SNMP>
<NTP>
<Address>10.0.0.2</Address>
</NTP>
</Configuration>
---
<Command>
<Dial>
<callSrc>Alice</callSrc>
<callDst>Bob</callDst>
</Dial>
</Command>
---
<Command>
<Boot/>
</Command>