Remote Administration via DLS within NAT environments (DCMP)

You are here:

Home  Devices  OpenStage  Remote Administration via DLS within NAT environments (DCMP)

Systematics
Family:	OpenStage
Model:	OpenStage 15 OpenStage 20 OpenStage 40 OpenStage 60 OpenStage 80
Relation:	SIP related
Release:	V2 R0

This feature enhances the existing OpenStage phone’s DLS interface by providing a means for the OpenStage SIP Phone to make use of a DLS Server which is deployed behind a Firewall/NAT. Supporting DLS usage in NATed environments like hosted HiPath 8000 environment, a DLS Contact Me Proxy (DCMP) was introduced with optiPoint SIP phones. This feature is now also available for OpenStage SIP Phones.

A detailed description can be found in the updated OpenWPI documentation for V2 R0

Short Overview

The DLS Workpoint Interface is based on an XML-based message exchange using HTTP over TLS (HTTPS) as transport protocol: the device (E.g. OpenStage) acts as client and initiates the message exchange by opening an HTTPS session to DLS. Sessions are opened due to specific device-driven events:

• the device restarts
• a configuration change has been done on the device (via local display or web-based man-agement)
• inventory changes of the device.
• logon or logoff of a mobile user on a (DLS-mobility enabled) device

However, in the case of DLS-driven events (E.g. pending jobs regarding configuration changes, SW deployment, file deployment), there must be the possibility for DLS to trigger the device to open a session.

The existing mechanism is the so-called Contact-Me request, an HTTP request sent by DLS to the device. The URL that is used by DLS to initiate a Contact-Me request, is derived from the so-called contact-me-uri, which is sent by the device to DLS at registration time:

DLS Workpoint Interface (WPI)

What is the Problem?

Device-driven events can usually be performed without restrictions: devices act as HTTPS clients and contact the DLS, which is a HTTPS server listening on a specific IP Address/Port. Even in Carrier or Hosted Business environments, the DLS can be seen as just an additional Web Server that replies to requests from the Internet. The Contact-Me request however inverts the client and server roles, which has significant impact in the following scenarios.

Problem #1: Firewall

Firewall(s) can be established between the network segment DLS is located and the network seg-ment(s), the devices are located. A typical configuration is that the devices are part of the customer LAN, while the DLS is located in a DMZ together with other administration and communication servers. Outgoing traffic from the DMZ (possibly maintained by a 3rd party company) into the customer LAN may not be allowed at all:

WPI Problem #1: Firewall

Result: DLS is not capable to inform devices about pending DLS jobs.

Problem #2: Network Address Translation

Today we are seeing more and more residential users moving to VoIP. Many companies also have small branch offices located remotely and also wish to deploy IP phones at these remote sites. Both residential users and branch offices are typically protected from the WAN or Internet by a router or firewall.

The corporate router or firewall generally induces a network address translation (NAT) to hide the internal IP-Address from the outside network. This makes it impossible to connect from the WAN/Internet to a phone deployed inside the remote branch office because its IP-Address is not visible from the outside world. Similarly, if the IP phone is deployed at home in a residential scenario, the home router/firewall also induces a NAT.

This makes it impossible to see the IP phones remotely in order that they can be administered by DLS: the contact-me-uri, which is sent by the device to DLS at registration time, contains the hidden IP-address, which is not addressable from the DLS' network location.

WPI Problem #2: NAT

Result: Again, DLS is not capable to inform devices about pending DLS jobs.

Solution Overview

To solve the Firewall/Nat traversal problems a DLS Contact-Me Proxy (DCMP) is deployed on a server in the same DMZ / location as the DLS server and has similar requirements to the connectivity as the XML-message part of the DLS Interface:

• Allow incoming HTTP requests from any location where devices are installed that need to con-tact the DLS.

Devices that suffer from the problems described in the preceding chapters, need to be configured to poll the DCMP periodically by issuing an HTTP request that determines whether DLS needs to be con-tacted or not:

Solution: DLS Contact-Me Proxy (DCMP)

The device polls the DCMP using a HTTP Request sent to the dcmp-url, which is obtained from the DLS. The device adds the parameter

contact-me?device-id=<mac-addr> 

to the URL where <mac-addr> is the Device ID as registered to DLS (item mac-addr).

For example:

http://dcmp-server:8080/dcmp/contact-me?device-id=0A:E8:F3:00:42:91

The decision criterion for the device is the HTTP return status code. The possible values are:

• 200 OK – No pending DLS jobs, a DLS session does not need to be opened
• 202 ACCEPTED – Pending DLS jobs available, the device should open a DLS session using the ReasonForContact = solicited

Two parameters are required for that purpose and can be set by DLS individually per device:

• the DCMP URL to be called
• the poll interval

Device Requirements

• Configuration of DCMP URL and poll interval via DLS. Note: the Contact-Me is still mandatory and to be supported in any case (and always active, independent of the device's DCMP configuration). Their current value need not to be stored persistently on the device: every restart of the device leads to a startup-request to DLS, where the current valid settings of these items are obtained.
• Execute poll requests at the required interval (in addition to listening on contact-me) and check HTTP return status code. The status code 202 ACCEPTED indicates that pending DLS jobs are available. The device should open a DLS session using the ReasonForContact = solicited. Note: Any contact to DLS (e.g. due to device start-up, local-changes, inventory-changes, etc.) should restart the timer for the DCMP poll interval

Data

dcmp-enable

Determines whether the OpenStage device will attempt to use thd DCMP procedures (i.e. contact the proxy at the address determined by the dcmp-url.

OCMS tag	dcmp-enable
New	Yes
Type	Boolean
Default	false
Profile	Device
Access	None (This data item is downloaded from DLS and not persisted on the device)
DLS/XML	Yes
Menu	No
WBM	No
Lockdown	No
User backup	No

dcmp-url

The URL of the DLS Contact Me Proxy.

OCMS tag	dcmp-url
New	Yes
Type	Boolean
Default	Null
Profile	Device
Access	None (This data item is downloaded from DLS and not persisted on the device)
DLS/XML	Yes
Menu	No
WBM	No
Lockdown	No
User backup	No

dcmp-interval

The URL of the DLS Contact Me Proxy.

OCMS tag	dcmp-interval
New	Yes
Type	Boolean
Default	Zero
Profile	Device
Access	None (This data item is downloaded from DLS and not persisted on the device)
DLS/XML	Yes
Menu	No
WBM	No
Lockdown	No
User backup	No