Siemens OpenStage Asterisk Product manual

HowTo
Siemens Enterprise Communications
www.siemens-enterprise.com
Issue 1.0
Siemens Enterprise Communications GmbH & Co KG
Munich, 09/07/2010
Germany
OpenStage@Asterisk
Installation and Maintenance
Guide

Open Communications Principles and Best Practices 19/03/2012, page 2
Scope
This document provides a best practice guide on setting up, operating, servicing,
and troubleshooting OpenStage phone in an Asterisk environment.

Open Communications Principles and Best Practices 19/03/2012, page 3
Contents
Scope 2
Contents 3
Preparation 4
Supplying Power for the Phones 4
Connecting OpenStage Phones to the IP Network 6
802.1x 6
LLDP-MED Configuration Options 6
DHCP Options 7
Plug & Play – One Step Provisioning and Configuration 7
Single Phone Configuration (Local Menu, WBM) 8
Using OpenStage@Asterisk 9
Busy Lamp Function (BLF) 9
XML Applications 9
Send URL / Remote Server Control 9
Call Completion (CCBS/CCNR) 10
CTI for OpenStage - UACSTA 10
Changing the Caller Information – PAI Header 11
Multi Address Appearance (MAA) 12
Automatic Call PickUp – Using Alert Info Header 13
Logging and Tracing 14
LAN Port Mirroring 14
Tracing Capabilities within the Phone 14
Basic Troubleshooting 14
Local and Remote Tracing 15
QoS Data Collection 15
Remote Control - the HUSIM Phone Tester 15
Limitations 17
References 17
Abbreviations 17

Open Communications Principles and Best Practices 19/03/2012, page 4
Preparation
This chapter contains all information that is necessary to connect an OpenStage phone to an
Asterisk based communication system.
This includes the power supply options (PoE or external supply) for each OpenStage model
and its possible sidecar combinations. To enable a secure environment, 802.1x support for
OpenStage is specified.
For autoconfiguration, LLDP-MED and DHCP can be used. In addition to the standard DHCP
options, SEN proprietary enhancements allow for assigning the address of a provisioning
service at phone startup for easy Plug & Play installation. By means of the provisioning
interface (WPI), mass deployment scenarios and remote administration during the phone’s
lifecycle are supported.
To facilitate configuration of a single phone by the administrator or user, OpenStage phones
feature a web interface in addition to the phone’s local interface.
Supplying Power for the Phones
The OpenStage phone family can be powered by
• External power supply
• Power over Ethernet (PoE)
Feature OpenStage
15
OpenStage
20E
OpenStage
20
OpenStage
20 G
OpenStage
40
OpenStage
40 G
OpenStage
60
OpenStage
60 G
OpenStage
80
OpenStage
80 G
Legacy optiPoint
external Power
Supply (EU-, US- or
UK-plug)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
Yes
(optional)
New OpenStage
Power Supply (EU-,
US- or UK-plug) In line with the further development of our portfolio we are now able to offer
smaller and lighter power supplies for all OpenStage and optiPoint 410/ 420/
500 variants.
They feature a higher degree of efficiency leading to 14 - 19% lower power
consumption, depending on the connected devices.
Important: The new OpenStage power unit is a device of product category.
The protection concept of the power installation needs to achieve the
requirements of earth conductor (e.g. Schukostecker Typ F, country specific).
Power over Ethernet:
IEEE 802.3af
Yes Yes
Yes Yes Yes
Power over Ethernet,
Cisco proprietary
mode
No No No No No
802.3af Power class OS 15: 1 OS 20E : 1
OS 20 : 1
OS 20 G: 2
OS 40: 2
OS 40 G: 3
OS 60 : 3
OS 60 G: 3
OS 80 : 3
OS 80 G: 3

Open Communications Principles and Best Practices 19/03/2012, page 5
Energy saving mode
To reduce the energy consumption to a minimum, OpenStage phones offer an energy saving
mode. The display backlight (phone and Key Module, if attached) is switched off after a
configurable timeout.
With OpenStage 40, the main display and key module backlight will be switched off after 90
seconds of inactivity (firmware version V2R0 onwards). Readability even without backlight is
ensured by the transflective display.
With OpenStage 60 and 80, the timer is configurable by the administrator (Local Functions
> Energy saving); the timeout ranges between 2 and 8 hours.
Power consumption [W] - Fast Ethernet variants
Energy saving
mode
Idle state During call
(handset)
Ringing (max.
vol.)
# of Key Modules Power over LAN (802.3af) Power via OpenStage switched-mode power su
pp
l
y
Power over LAN (802.3af) Power via OpenStage switched-mode power su
pp
l
y
Power over LAN (802.3af) Power via OpenStage switched-mode power
supply
Power over LAN (802.3af) Power via OpenStage switched-mode power
supply
OpenStage 15 - 2,0 2,9 2,0 2,9 2,3 3,2 3,9 4,1
OpenStage 15 with
1 OpenStage Key
Module 15
(9 LED’s on)
1 2,2 3,1 2,2 3,1 2,5 3,4 4,1 4,3
OpenStage 20/20E - 1,8 2,6 1,8 2,6 2,0 2,8 2,9 3,4
OpenStage 40 - 1,9 2,8 2,4 3,5 2,7 3,6 4,0 4,4
OpenStage 40 with
1 OpenStage Key
Module 40
1 2,1 3,0 3,1 4,2 3,4 4,4 4,6 5,1
OpenStage 40 with
OpenStage Key
Module 40
2 2,3 3,2 3,8 4,9 4,1 5,2 5,2 5,8
OpenStage 40 with
1 OpenStage Key
Module 15
(9 LED’s on)
1 2,1 3,0 2,6 3,7 2,9 3,8 4,2 4,6
OpenStage 60 - 2,4 3,3 5,6 6,9 5,8 7,1 6,8 7,9
OpenStage 60 with
1 OpenStage Key
Module 60
1 2,6 3,5 6,2 7,6 6,5 7,9 7,6 8,5
OpenStage 60 with
2 OpenStage Key
Module 60
2 2,8 3,7 6,9 8,3 7,1 8,6 8,3 9,3
OpenStage 80 - 2,3 3,2 6,3 7,7 6,5 7,9 7,6 8,6
OpenStage 80 with
1 OpenStage Key
Module 80
1 2,5 3,4 7,0 8,5 7,2 8,7 8,4 9,4
OpenStage 80 with
2 OpenStage Key
Module 80
2 2,6 3,6 7,6 9,2 7,9 9,5 9,1 10,2

Open Communications Principles and Best Practices 19/03/2012, page 6
Power consumption [W] - Gigabit Ethernet variants
Energy saving
mode
Idle state During call
(handset)
Ringing (max.
vol.)
# of Key Modules Busy Lamp Field Power over LAN (802.3af) Power via OpenStage switched-mode power su
pp
l
y
Power over LAN (802.3af) Power via OpenStage switched-mode power su
pp
l
y
Power over LAN (802.3af) Power via OpenStage switched-mode power
supply
Power over LAN (802.3af) Power via OpenStage switched-mode power
supply
OpenStage 20 G - - 3,6 4,7 3,6 4,7 4,0 5,0 4,5 5,3
OpenStage 40 G - - 3,8 4,9 4,4 5,6 4,7 5,9 5,2 6,3
1 - 4,0 5,1 5,1 6,4 5,5 6,8 6,2 7,4
2 - 4,1 5,3 5,9 7,3 6,3 7,7 6,9 7,9
- 1 4,6 5,8 5,3 6,6 5,6 7,0 6,4 7,4
OpenStage 60 G - - 3,8 4,9 7,0 8,7 7,4 9,0 7,8 9,4
1 - 4,0 5,1 7,7 9,3 8,3 10,0 9,3 10,3
Please see note *) 2 - 4,2 *) 5,3 8,4 *) 10,0 9,0 *) 10,7 10,1
*) 11,0
OpenStage 80 G - - 3,6 4,9 7,4 9,2 7,9 9,6 8,4 10,0
1 - 4,4 5,6 8,1 9,8 8,4 10,1 9,4 10,6
Please see note *) 2 - 4,5 *) 5,7 8,8 *) 10,6 9,2 *) 10,9 10,3
*) 11,5
*) These values are still within the 802.3af PD class 3, which allows up to 12,95 W, but they
are averaged, not maximum values. As soon as the USB interface is used, PD class 3 is
exceeded. Therefore, an external power supply has to be used for an OpenStage 60G/80G
with 2 Key Modules.
Connecting OpenStage Phones to the IP Network
802.1x
OpenStage phones support 802.1x EAP-TLS. Certificates for authentication can be
downloaded via the WPI.
LLDP-MED Configuration Options
OpenStage SIP phones support the layer 2 protocol LLDP-MED (Link Layer Discovery Protocol-
Media Endpoint Discovery). It is used for simplification of auto-configuration and network
management. The auto-configurable parameters of OpenStage phones are mainly the VLAN
ID, power consumption (power class) and quality of service (QoS) parameters.
LLDP-MED is able to replace various other established mechanisms like DHCP options,
manual configuration, or proprietary solutions like Cisco CDP. Example parameters are LAN
speed and duplex discovery, network policy discovery (VLAN and QoS capabilities) or
extended power via MDI discovery (PoE).
When an OpenStage phone is connected to a switch with LLDP-MED capabilities, the phone
is able to
a) advertise and receive a VLAN ID,

Open Communications Principles and Best Practices 19/03/2012, page 7
b) advertise and receive QoS parameters,
c) advertise the power requirements to the LAN access switch by means of an
"Extended Power via MDI” TLV.
Note: LLDP-MED should only be used with LLDP enabled network access switches. Older
network access switches that don't adhere to the 802.1D-1998 MAC bridging specification
might appear to be propagating the LLDP multicasts through the subnet. In this case, LLDP-
MED should be deactivated on the phone. For further information, please refer to the
OpenStage Asterisk Admin Guide [3].
DHCP Options
The following parameters can be obtained by DHCP:
Basic Configuration
• IP Address
• Subnet Mask (option 1)
Optional Configuration
• Default route (option 3)
• Static IP routing (option 33)
• SNTP server (option 42)
• Timezone offset (option 2)
• Primary/secondary DNS server (option 6)
• DNS domain name (option 15)
• SIP Addresses / SIP Server & Registrar (SIP Server option 120)
• Vendor unique (option 43)
The vendor specific option (code 43), or alternatively, a vendor class, is used to provide the
phone with the location of an optional configuration/ provisioning service. By this means,
full Plug & Play is possible (see the following section). For further information, including an
example configuration for dhcp, please refer to the OpenStage Asterisk Admin Guide [3].
Plug & Play – One Step Provisioning and Configuration
Provisioning via the WPI (WorkPoint Interface)
The WPI allows for controlling and provisioning the phone by a remote service using XML
messages which are transmitted over HTTPS. Unlike many other VoIP phones, which are
limited to prefabricated configuration files for download at startup time, OpenStage phones
exchange information with the provisioning service continuously. When local changes have
been executed on the phone, it will inform the provisioning service automatically.
Any kind of administration task is supported, for instance, updating the firmware on a
selection of phones, or setting SIP codes for server-based telephony features.
For further information, please refer to the WPI Developer’s Guide [8].
Plug & Play / Autoprovisioning
A fully automated mass rollout of OpenStage phones can be realized by combining a DHCP
server and the provisioning service. On startup, the phone receives the IP address of the
provisioning server from the DHCP server. After that, it contacts the provisioning service. The
provisioning service may then request all settings from the phone in order to decide which

Open Communications Principles and Best Practices 19/03/2012, page 8
parameters must be set or updated. When all these parameters have been sent to the phone,
it is ready for operation.
For further information, please refer to the WPI Developer’s Guide [8].
If a Firewall or NAT get in the Way
In case the phones and the provisioning service reside in different networks or subnets that
are separated by a firewall and/or NAT, it may be impossible for the provisioning service to
contact the phones.
To enable a solution for this problem, the phone can be configured to periodically poll
the provisioning service, or a special proxy, for new messages. Thus, provisioning service
driven interactions are possible even when the provisioning service is located behind a
firewall, or in a DMZ. For further information, please refer to the WPI Developer’s Guide [8],
Section 1.4.4.3, "Polling Request To Bridge A Firewall" and Section 3.1.2.2, "Provisioning
Service Located Behind A Firewall".
Single Phone Configuration (Local Menu, WBM)
Generally, it is recommended to administrate and configure an OpenStage phone installation
remotely using a provisioning service via the phone’s WPI (WorkPoint Interface). However,
there are two further configuration interfaces; these can be used to administrate individual
phones:
• Local menu: The user interface of the device itself.
• Web Based Management (WBM): The phone’s web interface.
Note: The default password for OpenStage administration is <123456>.
Local Menu
The phone’s application key ( ) is used to access the user and administration menu at the
phone.
Web Based Management (WBM)
The phone’s web interface can be accessed by any common web browser, like Firefox or
Internet Explorer. As HTTPS is used, the URL must be entered as follows:
https://<phone-ip-address>
If the browser displays a certificate notification, accept it.
Alternatively, the DNS name of the phone can be entered, if it has been configured and DNS
is available in the network.

Open Communications Principles and Best Practices 19/03/2012, page 9
Using OpenStage@Asterisk
This chapter contains some tips and tricks for operating OpenStage phones with Asterisk. It
is not intended to be exhaustive, but provides some major topics and solutions from
different successful customer projects.
Busy Lamp Function (BLF)
The “Busy Lamp Field” feature (available for OpenStage 15/40/60/80) allows users to monitor
the dialog state of another phone via the LED associated to an FPK. Please note that,
sometimes, the term 'Direct Station Selection' is used for the same functionality.
Depending on which function is configured for the FPK, the user can also pick up a call for
another user, which is of much use in working teams. The feature is described in detail here:
http://wiki.siemens-enterprise.com/index.php/
Asterisk_Feature_Busy_Lamp_Field_%28BLF%29#For_Users
XML Applications
OpenStage 60/80 phones feature a graphical user interface and an XML application platform,
which allows for developing custom applications based on HTTP/HTTPS. The phone acts as a
front-end for a server-side program. The interaction can be initiated by the phone or by the
server-side program. Besides displaying, modifying, and submitting data, XML applications
have the capability of starting calls on the phone. Possible uses for OpenStage XML
Applications might be
• Integration with groupware (e.g. Microsoft Exchange Server) or Unified Messaging
systems (e.g. Siemens Enterprise Communications OpenScape)
• phonebooks with access to address databases
• call recording
• presence applications
• collecting information provided by web services (e.g. news, weather, traffic, stocks)
• attendance clock
For detailed information, please refer to:
http://www.siemens-
enterprise.com/developerportal/Resource%20Center/OpenStage%20XML.aspx
Send URL / Remote Server Control
The FPKs and FFKs (firmware V2R1) can be utilized for communication with a server-side
program.
To enable feedback from the server, the LED associated with the key can be controlled
remotely. This can be done via SIP notify messages, or, with firmware version V2R2 onwards,
via a combination of HTTP push requests and XML documents. For detailed information,
please see the
OpenStage XML Applications Developer's Guide [9],
and
http://www.siemens-
enterprise.com/developerportal/Resource%20Center/OpenStage%20XML.aspx

Open Communications Principles and Best Practices 19/03/2012, page 10
Call Completion (CCBS/CCNR)
Call completion is a telephony feature which takes action on a failure to complete a call. It
allows for notifying the calling user when the called user is available again.
The OpenStage callback feature covers two conditions for call completion:
CCBS (Call Completion Busy Subscriber) : The called party is busy.
CCNR (Call Completion No Reply) : The called party does not respond.
Call Completion features can be implemented on a PBX, a dedicated server (e.g. a voicemail
Server) or directly on the client device (e.g. messaging applications).
There are several commercial companies which provide call completion features, as well as
IETF documents specifying call completion features for open standards, such as SIP.
The RFC 5359 gives a best practice example for call completion. However, the SEN OSCAR
group has evaluated this RFC with the result that it is not useful for a B2BUA architecture.
The IETF BLISS working group currently provides a draft paper (http://www.ietf.org/id/draft-
ietf-bliss-call-completion-06.txt) on how call completion can be implemented. However, no
RFC is available for this topic yet.
Although no standard has been released until now, OpenStage phones already support
server based call completion.
An implementation according to the IETF BLISS draft is planned, but currently not available.
The OpenStage call completion implementation is purely stimulus based and can be found
at:
http://wiki.siemens-enterprise.com/images/6/65/White_Paper_CC_10090.pdf
CTI for OpenStage - UACSTA
There are several use cases where remote control of a VoIP phone is required. Among these
are server based features like ‘Call Forwarding’ or ‘Do not Disturb’, or agent desktop
applications requiring a seamless desktop integration of the phone.
There is one ECMA standard in place which covers all those requirements: uaCSTA.
By means of the uaCSTA interface, the OpenStage SIP user agent can use call and device
control services at the SIP Server and vice versa. A complete set of CSTA services are defined
in ECMA-269 [6], which should be referenced for additional information.
The following subset of CSTA services and events are supported by OpenStage:
Services on the SIP Server:
 Set Forwarding
 Get Forwarding
 Set Do Not Disturb
 Get Do not Disturb
Events Generated by the SIP Server:
 Forwarding Event