Home » Archive » Skype for Business 5 minute Admin – Snom 300 UC Edition

Skype for Business 5 minute Admin – Snom 300 UC Edition

Today I have been getting to grips with the Snom 300 UC Edition phone. Nothing new to the Lync community, but it was a new experience for me. Largely the deployment of a single phone went pretty well but there was an interesting gremlin that I wanted to share with you all.

The Snom 300 UC Edition (version uses the Skype for Business DHCP options to discover some of the services required for the phone to register and DNS for the rest. An interesting output in the log file shows that the phone actually discovers the UCUpdates URL and asks the front end server for any approved firmwares! If only Snom released an nbt file, firmware could be loaded and managed by Skype for Business.

Anyway this is not the point of this post. The topology I was deploying the phones contained a backup Standard Edition pool. The behaviour experienced on the Snom phone was that the extension would not register with Skype for Business for long periods of time and then suddenly sign-in. Everything would then appear as normal until some point in the future the phone de-registered and then could not sign back in.

Looking at the Snom logs on the phone I could see register requests being sent and a 401 unauthorised and 403 forbidden response received. Running clslogging on the front end servers showed that the request was being refused by Skype for Business

Looking closer, I could see that REGISTER message was received by the backup FE and in turn was issuing the 401 and 403 responses as the user quite rightly was not registered to this FE.

Turning to the Snom logs again, I could see that the phone chose to register with the backup server as a result of a DNS lookup for the _sipinternal._tcp SRV record. In this case I have 2 SRV records set up like this:

_sipinternaltls._tcp.domain.com [0][10][5061] fe1.domain.local

_sipinternaltls._tcp.domain.com [0][20][5061] fe2.domain.local

And this is for client failover.

Removing the second DNS record and clearing the DNS cache solved this issue and the snom phone signs in perfectly. However, we leave ourselves open to issues when failover occurs.

Obviously this is not an ideal scenario so I looked at what could be done to ensure the phones could sign in consistently as well as have all records in place for failover. Thanks to @MartinBoam for his suggestion which ultimately led to the resolution.

It appears that we need to prioritise the SRV records as well as weight them. Changing the priority of these to the primary being 1 and DR being 2 now ensures the snom phone signs in properly.

_sipinternaltls._tcp.domain.com [1][10][5061] fe1.domain.local

_sipinternaltls._tcp.domain.com [2][20][5061] fe2.domain.local

Simple fix to an annoying problem.


    • Hi

      Yeah it would appear so, must admit I never googled the issue just figured it out so missed Doug’s blog post. There is a uc edition for 300 released in October 2014.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: