The new line of AudioCodes’ family of Lync-compatible IP phones, also part of their ‘One Voice for Lync’ portfolio, 400HD series consists of 420HD, 430HD and 440HD. These phones are said to have the following common features – Call  Waiting,  Call  Hold,  Call  Transfer,  Call  Forward, support for Lync conferencing services, , Hot Line, DND, Mute,  Speed  Dial,  Dial  Plan,  CWRR,  Call  Logs,  Auto Answer, 2 x Ethernet ports for PC and LAN connectivity and uses RTA & G711u/a.

A quick comparison between each model is as below




420HD is a cost-effective IP Phone   suitable for contact center deployments.Graphic multi-lingual LCD   display (128 X 48)4 programmable soft keys 430HD is a mid-range   enterprise IP  Phone.Graphic multi-lingual LCD display (132 X 64)

6 multi-function keys

12 programmable speed dial   keys with presence monitoring

4 programmable soft keys

Optional GbE Support

440HD is a high-end,   executive IP phone.Graphic multi-lingual LCD   display (132 X 64)6 multi-function keys

12 programmable speed dial   keys with presence monitoring

Lync contacts with presence displayed on dedicated LCD screen

4 programmable soft keys

GbE Support

The above info is from their product brochure – why re-invent the wheel, eh ?

I’ll have to admit that I’ve been used to and spoilt by Polycom’s Lync Phone edition (LPE) devices and the one thing that the 400 HD series lacks, at least in the first instance, is their primitive looking black and white / blue back lit LCD display. Even the ‘executive’ 440HD, looks very much like a standard PBX phone, but have a row of programmable keys. Having said that 420HD’s advantage lies in its price as it’s RRP is sub £100. In one of my recent device demo’s to a client, 420 HD was chosen to deploy to general users though I couldn’t ‘actually’ demo it working (due to a certificate issue mentioned later :) ).

Deployment Process

The deployment process for these phones are same as that of any Lync Phone Edition devices and Jeff Schertz does a better job (as always) here in explaining the process of configuring the necessary DHCP options.

In a nutshell the phone requires the following configuration


A records

pointing to the FQDN’s of the registrar servers.

SRV Records

_sipinternal._tcp.<SIP Domain>

_sipinternaltls._tcp.<SIP domain>

_ntp._udp.<SIP Domain>


Scope Option 43 – Lync certificate provisioning URL.

Scope Option 43 – VLAN ID. Only required if a separate VLAN is used or if LLDP is not supported by the switches.

Scope Option 120 – Lync Front end / Director Pool FQDN.

Scope Option 42 – NTP time server.

Scope Option 15 – DNS domain name.

Scope Option 119 – DNS search list.


Dial plans and call routing is configured and functional.

Users must be enabled for Enterprise Voice.

Decide on how the users will be logging into the phone

PIN Authentication. If using PIN authentication, make sure PIN policies are configured and that PIN is set up for the user.

AD credentials. Well, make sure they know what to use to log in (Email address . SIP address and password).



One of the issues I had with the phone was that it was failing to register / login. The phone was showing something along the lines of Verification failed for the domain <sipdomain>.

The logs from the phone were obtained by

Accessing the web web GUI http://<Phone_IP>

Default username ‘admin’ and password ‘1234’.

Status & Diagnostics –> Tracing

And it showed

local7.err voip_task[440]: CERT     : ERR  – {acl_user_tls_server_validation():653} server cert is invalid. ctx->error=7.

Resolution #1

This issue can be caused if you are unfortunate enough to use SHA256 hash algorithm on your CA that issued certs to Lync server. The AudioCodes phones only support MD2, MD5 & SHA1 encryption algorithms.

In this case you would either need to use another CA  with or change the CA you used for Lync and the phones to use SHA1. Changing encryption algorithm on a CA is said to be tricky. I have to be honest and say that I haven’t tried this before. Entry here gives a certutil cmdlet to change hash algorithm to SHA1.

1.On the Server where you have your CA installed, open a command line prompt and type:

certutil -setreg ca\csp\CNGHashAlgorithm SHA1

2.This will update the MMC CA immediately, but to ensure the CA uses this new algorithm when it issues certificates, you must restart Certificate Services.

3.Issue a certificate from the root, and verify that the signature uses SHA1 in the details tab / signing algorithm field on the certificate.

There may be another option (I haven’t tried it though) – if you have multiple CA’s in your environment, you could configure these devices to use SHA1. This could be done by uploading the certificate manually on the device using the web GUI.

Resolution #2

The same issue could happen if you are trying to log into the phone for the first time, but externally.

Phones that are to be deployed externally will need to be first provisioned  by logging in to the device whilst within the network. This is so that the phone could obtain certificates automatically. Else as above, you can always upload the certificate manually on the device using the web GUI.

Hope that helps.