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 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=184.108.40.206;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.