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) [0]0E14.0534::04/16/2014-00:47:29.882.00056b1b (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(196))[2176820743] $$begin_record
Trace-Correlation-Id: 2176820743
Instance-Id: 1D389
Direction: incoming;source="external edge";destination="internal edge"
Peer: exap.um.outlook.com:5061
Message-Type: response
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
Call-ID: 6fa3ea88-1a4e-4e6b-91f5-020e6fca17b8
CSeq: 57916 CANCEL
Via: SIP/2.0/TLS [edge external ip]:55657;branch=z9hG4bK3F146DB3.F6B41C17EA0CAB08;branched=FALSE;ms-internal-info="dsv_8mXtT4SLlqwtIRgewpQLjKclLYLYWQ3cBo05Vq-5wXHLT2A9YY0QAA";received=111.221.77.9;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
Content-Length: 0
ms-split-domain-info: ms-traffic-type=SplitIntra
$$end_record

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.