My team were setting up a new tenant this morning on our LHPv2 system, and connecting the tenant to Office 365 for unified messaging. They called me to help with what they thought was a problem with Office 365 not accepting the call, but it turned out to be something a little different.
The error message from OCSLogger:
TL_INFO(TF_PROTOCOL) 0E14.0534::04/16/2014-00:47:29.882.00056b1b (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(196)) $$begin_record
Direction: incoming;source="external edge";destination="internal edge"
Start-Line: SIP/2.0 481 Call Leg Does Not Exist
From: <sip:[tech's mobile];phone-context="DefaultProfile@mycompany.com.au;user=phone">;epid=2EE952F746;tag=6cb59ace1
To: <sip:[umsa number];phone-context="DefaultProfile@mycompany.com.au;user=phone">;tag=8585D2CC6F45A929C4653EC37D6C34E5
CSeq: 57916 CANCEL
Via: SIP/2.0/TLS [edge external ip]:55657;branch=z9hG4bK3F146DB3.F6B41C17EA0CAB08;branched=FALSE;ms-internal-info="dsv_8mXtT4SLlqwtIRgewpQLjKclLYLYWQ3cBo05Vq-5wXHLT2A9YY0QAA";received=126.96.36.199;ms-received-port=55657;ms-received-cid=76A73700
Via: SIP/2.0/TLS [edge internal ip]:55702;branch=z9hG4bK94BC93A2.E2C841E49AD07B16;branched=FALSE;ms-received-port=55702;ms-received-cid=14800
The mobile phone trying to call the UMSA number didn’t hear any ringing during call setup – it would just stay silent for about a minute before finally timing out and failing, which is about when the above error appeared in the log.
Putting the log side by side with a working call made it obvious that there was a problem. Here’s the failed call on the left, versus a successful call on another Lync deployment on the right:
So what’s the problem? Well, it’s pretty simple, actually:
Turns out the _sipfederationtls._tcp record hadn’t been created during our normal provisioning process. Once we added this DNS record, everything started working as it should.
How did we figure that out? When Lync sets up the SIP call to Office 365, there’s a requirement there that Office 365 can get back to us. To do this, it uses the _sipfederationtls._tcp SRV record so it knows where to route traffic back to us. The fact that we were able to get there and nothing seemed to be returning pointed us in that direction.
If you haven’t heard, Heartbleed, aka CVE-2014-0160, is a vulnerability in OpenSSL – a cryptographic library which is used to secure a bunch of internet services via SSL/TLS. When you see the green https at the left hand side of your browser’s address bar, there’s a good chance that OpenSSL is behind the scenes, silently encrypting your data before sending it to you.
If you’re curious about how Heartbleed works, check out this excellent comic from XKCD.
Unfortunately (or fortunately, depending on your point of view), some boffins have discovered that OpenSSL has a bad habit of allowing anyone on the Internet to probe the server and retrieve the contents of its memory. This memory could contain anything, but the biggest thing we’re concerned with is our own data, specifically usernames and plain text passwords.
Most companies have patched their OpenSSL by now, but it’s better to be safe than sorry. You can use the Heartbleed Test to see whether a site you’re interested in has updated.
And what should you do? Change your Passwords. Actually, you should take this opportunity to set them so they’re different on all your services, because having the same password on everything isn’t a good idea.
If you need help keeping track of all your passwords, have a look at KeePass - it’s an app which keeps your passwords in an encrypted file which you can store on a local disk or in the cloud – Dropbox or OneDrive, for example. Once you enter the master password you can retrieve your passwords and use them wherever you need to. There are Windows, Windows store, Mac and Linux versions of the app so you won’t be out in the cold. There’s even a Firefox plugin for it.
Microsoft have just announced the latest
cumulative update for Lync server 2013 update for the Lync 2013 client.
Edit: Turns out this is actually a client patch, which wasn’t telegraphed too well when the patch was first announced, hence the confusion. Regardless, it’s an impressive list of fixes which you should consider testing in your lab before deploying to your users.
There are a number of fixes and feature additions, including fixes to desktop sharing, speeding up of network recovery after a loss, and the addition of a button which displays when a user is connected to a backup pool which will display what features are going to be lost.
Check it out here.
I don’t know about you guys, but typing my password in whenever I want to get to one of my home servers is… well, it’s damn annoying. Thankfully there’s a way to export your private keys so when you log in to a computer you trust, you can have this act as your authentication mechanism – because you have a preshared key, the target server won’t bother asking you for a password.
First, install MPG123, a super simple command-line media player:
aptitude install mpg123
Then fire the following (or save it as a script):
find /path/to/your/mp3/files/ -name '*.mp3' | mpg123 -Z -@ -
Find will pull a list of mp3 files in the specified folder, randomize them, and push them in to mpg123. Control-C will skip tracks and Control-Z will kill.
Props to Daniel Howard for first posting this here