One of the things that many clients want with any deployment is the option for at least a few wireless handsets. Whilst it could be argued that Lync 2013 offers a range of options when it comes to supporting a wireless client over Wi-Fi or 3/4G, it’s not always the magic bullet we would all like it to be. Internal Wi-Fi networks can sometimes be less than ideal, particularly when attempting to support real time communications, and it’s still common to come across 3/4G black spots, particularly when inside a building or in regional areas. There is of course another technology option if we would like to support medium range wireless telephony within our Lync deployments: DECT
We’re all familiar with DECT, or Digital Enhanced Cordless Communications. It’s the same technology we’ve had in our homes for years, and is utilised today by a range of Lync certified wireless headsets (some examples can be found over at Plantronics and Jabra). What’s been missing is a native Lync DECT handset solution.
We can all be thankful then that Spectralink have a range of handsets that have been tested and qualified for use with Microsoft Lync 2010 and 2013, in both WiFi and DECT models. This article focuses on Spectralink’s DECT offering, providing integrators with a DECT wireless option when deploying Enterprise Voice for their customers.
There are a range of DECT handsets to choose from, each targeting a specific vertical:
|Butterfly Series||Light use office environments|
|75 Series||Mobile worker/administration environments|
|74 Series||Harsh environments (oil, gas)|
The Spectralink 7000 Site Survey handset is also available, which looks to be a handy tool for integrators deploying Spectralink DECT networks. Looking forward to trialling this in the future.
The DECT handsets subscribe to an IP-DECT server, which in turn communicates with the Lync environment. The system could consist of a single IP-DECT server and a few handsets, right through to a network of IP-DECT servers, base stations and repeaters that support hundreds of handsets.
There are two flavours of IP-DECT server:
|IP-DECT Server 400||SMB, 30 wireless users, 12 voice channels|
|IP-DECT Server 6500||Larger organisations, modular, supports up to 4,096 wireless users|
Note that the number of channels supported by each server version is reduced when Secure RTP (SRTP) is enabled between the Spectralink servers and Lync.
DECT Base Station/Repeater
The IP-DECT base stations are controlled by the IP-DECT server, providing a link between the handset and the IP-DECT server. The DECT repeater can be used to extend the coverage of the DECT servers/base stations.
|IP-DECT Base Station||Over the air call signaling between the IP-DECT server and handsets|
|DECT Repeater||Building block that extends the DECT coverage area|
For smaller deployments, the IP-DECT Server 400 combines the role of server and base station into a single unit. For larger deployments, the IP-DECT server requires the deployment of at least one IP-DECT Base Station. Both servers support the deployment of DECT repeaters, however these are not a required component:
I’ve referred to the following guides when configuring integration between Spectralink and Microsoft Lync Server 2013:
Spectralink IP-DECT Server 400 Installation and Configuration Guide
Spectralink IP-DECT Server 400 and 6500 and Microsoft Lync Server Configuration Guide
- Choose a FQDN for your Spectralink server, and add it to DNS. In this example, I’m using DMU-DECT400.dmunified.com
There are two methods that we can use to register a user to Lync: System Authentication (Trusted Server) or User Authentication (NTLM):
- Trusted Server method – When configured this way, the Spectralink 400 server is setup as a trusted application server within the Lync environment. When configuring user accounts from the Spectralink Web GUI, only the SIP prefix (e.g. Damien.Margaritis) needs to be specified. It’s also possible to change the SIP prefix from the handset instead of the Web GUI, something you can’t do when using NTLM authentication (there’s no way to enter AD credentials from the handset).
- NTLM method – When configured for NTLM authentication, the Spectralink 400 server is not added as a trusted application server to the Lync environment. Because of this, each user that’s configured via the Spectralink Web GUI will require AD username and password details to support NTLM authentication.
In this blog article, we’re going to configure the Spectralink server as a trusted application server from the Lync Management Shell (this is Spectralink’s recommended method)
Configure Trusted Application Server
From the Lync Management Shell:
- If you don’t know your Lync Site ID, run Get-CsSite first and note it down
- Run New-CsTrustedApplicationPool -Identity DMU-DECT400.dmunified.com -Site DMUNIFIED -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true -Registrar lyncpool01.dmunified.com
- Click Y when presented with the topology publishing warning (this is expected). You should see something similar to this:
- Run New-CsTrustedApplication -ApplicationId DECT -Port 5061 -TrustedApplicationPoolFqdn DMU-DECT400.dmunified.com
- Run Enable-CsTopology
Spectralink 400 Server Configuration
- From the Web GUI, open Configuration > General, and configure the following settings:
Make sure your firmware version is up to date (at time of writing, latest version was PCS14, download here.
- From the Web GUI, open Status > General. Confirm the PCS version is current
To support integration with Lync, a license is required. Make sure this is applied:
- From the Web GUI, open Administration > License
- Copy the License key into the License field, and click Load
- Reboot the server. You should now see the Lync license applied:
Enable Lync Support
- Open the Web GUI to Configuration > Lync, and select both options, and click Save
So that media communication is secured between endpoints, you’ll need to import your Internal CA Root Certificate and Create/Import a host certificate.
Import Root CA certificate
To obtain the root certificate from your internal CA:
- Open a web browser to your internal CA (for example, mine’s http://dmu-dc01.dmunified.com/certsrv)
- Select Download a CA Certificate, certificate chain, or CRL
- Ensure Base 64 is selected, and click on Download CA Certificate
- Back on the Spectralink 400 server, open Configuration > Certificates
- Under CA Certificates, browse to the root CA you exported above, and select Import List. This will replace the default list with your internal root certificate
Create/Import Host Certificate
From your Lync Front End server, open IIS, and select Server Certificates
- From the menu on the left, click on Create Domain Certificate…
- For the common name, ensure you enter in the FQDN of the Spectralink server that you entered into DNS earlier. Fill in the rest of the details, and complete the wizard
- Right click the new certificate, and click on Export
Choose a file location to export to, set a password and click OK
- Import the Host Certificate onto the Spectralink Server. From the Web GUI, open Configuration > Certificates
- From the Host Certificate Chain section, browse to the certificate file location, enter in the password and ensure you select PKCS#12
- Click on Import Certificate
Reboot the server
SIP Server Settings
- From the Web GUI, open Configuration > SIP
- Configure the following settings:
|DNS Record||A records|
|Use SIPS URI||Unselected|
|Proxies||1: sip:dmu-sba01.dmunified.com2: sip:lyncpool01.dmunified.com
|Ignore SDP Version||Selected|
|Enable media encryption (SRTP)||Selected|
|Require media encryption (SRTP)||Selected|
|Include lifetime in SDES offers||Selected|
|Include MKI in SDES offers||Selected|
Note: In my lab, I have two Front End pools and an SBA. A single entry for proxies is fine.
- Save and Reboot
Configure Lync User/Handset Registration
At this point, if you try to register the handset against the Spectralink server, it will fail:
For this to work, you first need to enter in the phones IPEI number from the Spectralink Web GUI, along with the Lync user’s SIP prefix.
- From the Spectralink handset, go to Menu > Settings > Status > General Information, and note down the IPEI Number
- Open the Spectralink Web GUI to Users
- Click on New
- Enter in the IPEI number of the handset, the standby text you want displayed for the user (optional), and the users SIP prefix in the Username/Extension field
- You should now have a successful registration against the Lync server
- From the Spectralink DECT handset, go to Menu > Settings > Advanced > Login > Create Login
- Select the Spectralink ARI number you want to register against (can be found on the base of the server or from the user list Web GUI). On the next page, click ok. You should now be connected:
From the Spectralink Web GUI, you should now have two ticks: one for Subscription from the DECT handset to the Spectralink server and one for the successful registration against the Lync server
Now that we’ve completed the configuration, you should have no issue getting a call inbound/outbound from the DECT handset:
For a list of known limitations when using the DECT handsets in a Lync environment, refer to Chapter 8 of the Spectralink IP-DECT Server 400 and 6500 and Microsoft Lync Server Configuration Guide. The limitation I found to be the most annoying when testing various call flows is the lack of Response Group call information for incoming Response Group calls (only the calling number is displayed).
I hope you have found this blog post useful. If you would like to know more about Lync and Spectralink, would like a demo or would like to talk more about a solution that’s right for you, feel free to get in touch: email@example.com.
Great post. What changes in the settings would be required from your post if you didn’t do encrypted? Also is the DECT base station required for the handsets to talk to the DECT server, or can the DECT server act as a base station for handsets?
To support unencrypted configuration (TCP), I would say that the certificate configuration would not be required, the SIP configuration on the IP-DECT server would need to be changed to TCP, and the trusted application configuration in Lync would need to be changed to enable TCP. Personally, I’m a fan of keeping all comms secured where possible.
If you’re deploying the IP-DECT 400 server, the handset communicates directly with the server (it’s effectively the server and base station in one, and is the setup I used when writing this blog). If you’re deploying the IP-DECT 6500 server, you would use at least one base station for the phones to subscribe against (the 6500 is a rack mount server located in a cabinet, whilst the 400 is deployed out on the edge). The base stations communicate via IP back to the IP-DECT server, however repeaters, if deployed, are not wired back into the IP network. They increase DECT coverage only.
Spectralink have released a guide that looks at when to you base stations, and when to use repeaters: http://support.spectralink.com/sites/default/files/resource_files/Spectralink%20Base%20Stations%20or%20Repeaters.pdf
Hope that helps
Updated article with diagram showing example infrastructure topology for SMB and Enterprise deployments.
FYI – changing a trusted application to TCP will not allow UCMA applications to interact with Lync as MTLS is a requirement. By the sounds, changing the trusted app to TCP will break the functionality that the DECT server provides.
My 2 cents.
Nice Article Damien.
I am told that the Kirk servers 400 and 2500 cannot communicate with a remotely hosted Lync service deploying Edge servers – is there a way around this?
Are you asking if there is a way for the Spectralink servers to communicate to a remote deployment of Lync via Edge servers? I would not expect this to be supported. I would recommend employing a WAN connection between Lync deployment and Spectralink servers to support integration.
Thanks, this is well laid out and helped a lot.
I have configured a solution with Lync 2013 and a Spectralink 400 IP DECT server with two 7540 handsets but am having an issue with transferring external calls from the Handset to anywhere.
Tried to transfer to a contact in the Phonebook and manually dialing the number.
Hoping you may have some insight.
Unfortunately, I haven’t been hands with the Spectralink phones for quite some time. I’ve been patiently waiting for Polycom’s D60 DECT handset Lync/Skype for Business firmware to become available… That said, you could try disabling Refer Support if it’s enabled? This is a common culprit when there’s call transfer issues with 3rd party vendors.
Forgot to mention that I did try disabling refer, as well as the encryption options but still getting the same error, which comes up as a 401 “unauthorised” error. Not sure if that helps. Any ideas. I have been sending captures and logs to Spectralink but so far no success.
Have you heard anything about the D60 and Lync/Skype? Can’t seem to find anything as far as any kind of support for the future.
The D60 was supposed to be Polycom’s DECT device to use with Skype for Business, but unfortunately they never released the Skype certified UCS firmware. At this point, it’s unclear if Polycom plan to do this at all. I was hoping this would be the case, it would have rounded out Polycom’s device offering for Skype for Business nicely.
Managed to resolve this issue. Installed the latest Lync 2013 updates and upgraded the firmware on the SBC.
Just a heads up for those using the Spectralink – we have upgraded our Lync 2013 to Skype For Business and it is working working. Clearly your mileage may vary.
i am interested in knowing the call flow to and from the spectralink to the Lync server
as well as the ports that needs to be opened on the firewall for the flow and the signaling
i integrated the spectralink already with Skype as a trusted app, pending on the flow and ports
hope you can advise
I’d check Spectralink’s documentation for port requirements, although I would expect them to be standard SIP signalling/media port ranges. Wire shark will confirm if you’re wanting to confirm