Recently, we have been engaging with a customer to unravel their Lync 2013 Enterprise Voice. Over the years, they have had to “work around” several different carrier situations and voice gateways. And none of their solutions have been on the Microsoft approved/supported list. What list is that? Well, Microsoft developed the Open Interoperability Program (OIP) to qualify hardware, software, and services for the Microsoft UC Ecosystem. A good place to start looking for details is the Skype for Business Solutions Catalog. If you want to verify SIP and E911 providers here is the list for Lync 2010/2013 and for Skype for Business 2015.
They are located in an interesting crossroads where there is no “large/approved” carrier that can provide dial tone. They are having to find SIP providers – again, none are on the OIP – to give them local numbers. Each of those SIP providers use various methods of IP Security and SIP User Authentication for registration. Over the years, they have implemented interesting solutions like “Siperators” and asterisk boxes and other methods in order to get signaling into Microsoft Lync/Skype.
(insert head banging)
We worked with them to properly spec an Audiocodes Mediant 1000 SBC to consolidate all of their various needs to have a primary (and approved!) SBC for Microsoft Lync/Skype. We took out the Siperator (did you know Siperator was a thing? I didn’t) and got the SBC in production for SIP Carrier #1 and Lync 2013. That was fine. We consolidated their 911 emergency services on the SBC. That was fine.
The next step was to integrate one of their SIP providers that requires user authentication (username and password) in order to SIP REGISTER for service. That was interesting. It worked just fine. The Audiocodes SBC wil do the user registration for you and then sends SIP NOTIFY to Microsoft Lync/Skype. Properly configuring SBC Routing sent the voice call. That was also fine. But, Lync/Skype rejected the call. That’s *not* fine.
See that? I called in (from my 502) number to the customer (a 309 number) and the call was rejected from Lync with a SIP 488.
The error message from Lync 2013 itself was “SIP/2.0 488 Invalid incoming Gateway SDP: GatewaySDP: Unrecognized transport profile”.
What does that mean? Well, something in the SDP didn’t match.
Let’s compare a “good call” with this customer – from their “known good” SIP provider.
And let’s go back to the failed call and compare that SDP:
Most everything looks fine, but this line is odd:
Lync doesn’t speak “a=setup:actpass”, so that wasn’t going to fly. Without getting into an RFC (then updated RFC, then updated RFC) holy war, just know this doesn’t work.
We needed to somehow adjust the SDP from this SIP Provider as it travels via the Mediant 1000 toward Lync.
There is an entire document you can download from Audiocodes.com called the SIP Message Manipulation Reference Guide and it helped us here. We wanted to “normalize” the body of this SDP.
So, we created our rule…
From there, we had a rule that normalized our SDP policy. And we needed to apply this. Where? The IP Group of this SIP Trunk Provider:
Does that make sense? We received a call from this SIP Provider, we applied Manipulation Set 1 (to normalize the SDP body). Then, assuming all of our other settings related to manipulation and routing are correct, the call should have worked.
Excellent. Notice the SDP? Any of those weird non-standard items (like a=setup:actpass) are removed. The call works perfectly.