Difference between revisions of "Remote Administration via DLS within NAT environments (DCMP)"
The Wiki of Unify contains information on clients and devices, communications systems and unified communications. - Unify GmbH & Co. KG is a Trademark Licensee of Siemens AG.
(→Solution Overview) |
|||
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | {{Breadcrumb|0|0|{{dev-en}}|OpenStage}} | ||
{{OS-FD-Access}}{{FD-Sytematics-Box | {{OS-FD-Access}}{{FD-Sytematics-Box | ||
| family = {{FD-Cat|OpenStage}} | | family = {{FD-Cat|OpenStage}} | ||
Line 11: | Line 12: | ||
== Short Overview == | == 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: | ||
+ | |||
+ | [[File:DLS Workpoint Interface (WPI).png]]<br /> | ||
+ | ''DLS Workpoint Interface (WPI)'' | ||
== What is the Problem? == | == 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: | ||
+ | |||
+ | [[File:WPI Problem 1 Firewall.png]]<br /> | ||
+ | ''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. | ||
+ | |||
+ | [[File:WPI Problem 2 NAT.png]]<br /> | ||
+ | ''WPI Problem #2: NAT'' | ||
+ | |||
+ | Result: Again, DLS is not capable to inform devices about pending DLS jobs. | ||
== Solution Overview == | == Solution Overview == | ||
Line 20: | Line 60: | ||
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: | 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: | ||
+ | |||
+ | [[File:DLS Contact-Me Proxy (DCMP).png]]<br /> | ||
+ | ''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: | ||
+ | <nowiki>http://dcmp-server:8080/dcmp/contact-me?device-id=0A:E8:F3:00:42:91</nowiki> | ||
+ | |||
+ | 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 == | == Device Requirements == |
Latest revision as of 00:02, 22 April 2011
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
Contents
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:
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:
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.
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 |