Here is a view of my house; I rolled back the rock the other day and ran into a little PIN Authentication issue.
As we know, since Lync 2013 and the advent of the full-blown LyncDiscover.domain.com and LyncDiscoverInternal.domain.com concepts, the Lync 2013 (and now SfB) client does not need anything to accomplish a login other than being able to find LyncDiscover which then tells the client where to go. You can read up on this here.
Where’s the Beef?
I recently ran into an issue with SfB PIN Authentication while using AudioCodes 420HD handsets. The phone would login using UPN – e.g. email@example.com with a password. As you know, this can be a royal PITA doing the alphabet soup thing on a 3x4 dialpad. Configuring the phone via web for login credentials worked also. But the same user could not use PIN Auth. And using the phone as a common area phone, where the UPN does not exist, did not work at all. The phone would come back and say that the account name or PIN was not correct. Futzing around with it for a goodly amount of time would sometimes give us a failure to find the Lync Server. Hmmm.
The killer is that all the desktop clients in the environment could login just fine, and to make matters worse, a Polycom VVX600 could login with PIN AUTH for real CSUser accounts as well as the common area phone that failed to login to the 420HD.
So, off we went looking for a solution.
A Bit more Background
DHCP got checked. It was perfect. Right down to the Time Zone offset. All was good. We spell checked all of the settings – not expecting to find anything (the UPN login worked), but doing our due diligence.
We then went looking at phone traces, CSLogger output on the FE pool, and finally port mirroring on the phone itself. What we saw was the phone discovering DHCP, getting an address, and generally being successful. But failing for PIN Auth. CSLogger showed wonderful results when using a UPN login, but Snooper revealed that when doing PIN Auth, the phone never contacted the pool. There was simply nothing. Ouch. Back to the phone for some port mirroring to attempt to see what was what.
OK, see all that? What the 4xxHD phone is doing is cranking through a raft of hard-coded lookups based on the DHCP information presented in the form of the domain name. Look at what is failing.
Reading the first bit of AudioCodes documentation does not mention those DNS records the phone is obviously looking for. I started with LRTR-09937, which is the latest (and supposedly greatest) administrators guide for 4xxHD phones. Section 2.1 (page 17) has this list.
Further down on page 32 I see this:
Uh oh. I think I am seeing a pattern here.
But, down on page 139, we have some troubleshooting tips, which by the way, are the exact errors we were seeing…Note that there is no mention of SRV records…
LTRT-21920, which is specifically for the phone model in question, has the exact same information in section 5.2.1
And finally, we find this little gem (LTRT 21920 page 9 if you are following along):
Off we go to check the DNS requirements per Microsoft documentation…
THEN I find this: https://technet.microsoft.com/en-us/library/gg412806(v=ocs.14).aspx which states:
This section describes the hardware, port, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and security configurations that must be in place before you deploy IP phones…
Oh yes, I remember that, and still I have to ask why does UPN work and not PIN Auth, and why does the Polycom have zero issue either way, yet the 4xxHD will only do UPN and not PIN Auth.
Why four different pages I have no idea, but there you go.
Another question is why a Polycom does not seem to need these records to operate successfully – but I don’t have an answer to that – we will assume the Polycom UC firmware/software is more updated perhaps?
OK, back to our DNS server in question and wala! no _sipinternaltls._tcp.domain.net. So we add that. Reboot the phone.
The only conclusion I can reach is that AudioCodes 4xxHD phones are still acting as a legacy client, and therefore need the legacy SRV records to function properly.
A question remains, though, as to why the exact same phone will login with a UPN without the legacy records yet fails PIN Auth. Same firmware, different result. I guess I will go back to recommending that all DNS records for legacy and Lync 2013/SfB be implemented just in case.