We recently deployed Lync Server 2013 Enterprise Voice for a customer who at the same time replaced their old Mitel PBX with a newer Mitel 3300. The customer wasn't ready to make a full commitment to Lync for voice traffic, but probably 80% of the customer's users are using Lync exclusively for voice.
The Lync infrastructure was connected to the PSTN via the Mitel 3300 PBX using direct SIP. While things initially seemed to be fine, we were getting numerous reports of sporadic failed calls throughout each day.
Digging through the monitoring server reports (deploying monitoring server reports should be considered ESSENTIAL for any Lync Enterprise Voice deployment), we could see a clear trend for the call failures: Looking at the Failure Distribution Report, we could see the top failed call reason was Gateway side Media negotiation failed.
Clicking on the sessions number hyperlink brought us to the list of calls that failed due to that cause. Selecting one shows the session detail report for that call:
At the bottom is the Diagnostic Report. Clicking the Detail link on the server side finally shows the exact reason for the call failure:
10010; source="LyncFE.contoso.com"; reason="Gateway side Media negotiation failed"; component="MediationServer"; ValidationError="SDP Exchange already failed before SetAnswer: Session c line = 0.0.0.0 or ::, call hold not allowed for initial INVITE offer"; GatewayFqdn="10.1.1.2; trunk=NA-OH-Dayton-Mitel"I did a search through my normal channels and didn't come up with much. I saw a few references to clients who set the Lync client audio port range to 3, rather than the recommended 20-40 which caused their particular issue, but we were already using 40 as a client port range.
It seemed as though the issue was coming from the Mitel side. I tried a few things like setting the trunk's RTCPActiveCalls and RTCPCallsonHold values to FALSE on the Lync side, but that had no effect.
We tried to contact the Mitel partner who put in the Mitel system, but they were of very little help. I asked if I could poke around the Mitel web console to look for a potential fix. Surprisingly, the client said "Sure". Having never seen a Mitel before, I thought that things were about to go very wrong, or at least we wouldn't get any closer to a solution.
Since the error was related to SDP, we focussed on the SDP Options tab under SIP Peer Profile on the Mitel. The most promising option was Avoid Signalling Hold to the Peer. It was promising because the error message from the Lync monitoring reports mentioned both SDP and hold, so.......we set it to Yes, and at the same time we set Enable Mitel Proprietary SDP to No. Everything else we left alone.
Almost immediately, our problems came to an end. Calls to numbers that would fail every 2nd or 3rd attempt suddenly worked without error every single time. Another side benefit was that we were now getting music on hold when transferring to Mitel call queues, where we weren't before.
I was amazed that we had brought up the issues around both music on hold and the failed calls on numerous occasions, and the Mitel partner could not find a solution, while someone with zero experience with Mitel was able to find a solution in under 10 minutes of poking around.
I was feeling pretty good about fixing that issue, so I tried to solve the other remaining issue where outbound calls would only show the main office number rather than the individual Lync user's DID. However, my beginners luck ran out and I couldn't find a solution.
So, if you're having similar issues with a Mitel - Lync deployment, hopefully this will steer you in the right direction.
0 comments:
Post a Comment