Today is more of a cautionary tale with a bit of step-by-step problem resolution at the end, and while this has the proverbial happy ending, it didn’t have the happiest of rides to get there.
Our tale begins last year when a client went with a new SIP provider. This sort of thing sometimes happens and isn’t always a bad thing. This time it was, since the client went with a SIP provider that’s not on the Microsoft Certified list.
We knew things had potential to get a little wonky. It started off well enough — the port order went in, numbers got ported, we did the configuration, and things looked good. Then we discovered that not all the numbers got ported to their SIP trunk.
We got to digging and found out that since these specific numbers had been assigned to analog lines — through the same company, mind you — and they were in a different service plan area they couldn’t be ported out. Of course, for a small fee, they could set up call forwarding of the numbers to other DIDs on the SIP trunk.
In all fairness, this single issue isn’t just confined to providers that aren’t on Microsoft’s list. Sometimes you just can’t port a number out of an area. Our client was understanding and for the interim decided to have the numbers forwarded and go about their merry way.
However, we soon discovered that every time you placed a call on hold and resumed the call, audio both directions was lost. The call appeared to stay connected, but no one could hear anything.
Now you may ask, “Russ, didn’t you test this when you ported the numbers over?” Yes! We tested it. It worked. Now, suddenly, it doesn’t. What gives? Time to call the provider.
The provider pulled traces on their side, we pull traces on our side. Time is spent analyzing everything from logs from CLSLogger to Syslog off our SBC. They compare to other clients and after much hair pulling and discussion say that everything looks good from their end, it must be an issue with the SBC. Time to call AudioCodes.
The client has an AudioCodes Mediant 800. I’ve installed more of these than I can count. I would run out of fingers and nobody wants me taking my shoes off to keep counting. I opened a ticket with AudioCodes and did the song and dance again: placed test calls, pulled logs, analyzed said logs … and AudioCodes concluded that it wasn’t an issue on their side, and if the provider says it’s not on their side, then they recommended we talk to Microsoft.
After opening a ticket with Microsoft, I got on the phone with them and it quickly became apparent that everyone went to the same dance school: place test calls, pull logs, analyze said logs, wash, rinse, repeat. Microsoft, to their credit, went that extra three miles and went over the implementation with a fine-toothed comb as well. It was during this troubleshooting that we found where the problem was.
Take a look at this:
This is the invite that gets sent when the call is put on hold. This is sent from Skype for Business out to the SIP provider. Now look here at the 200 OK that we received from the provider:
Notice anything missing? That’s okay if you don’t see it right off because AudioCodes, the provider and I all didn’t see it either. We had just been looking at things as a whole: well here’s the invite, there’s the OK, there’s the ACK … where’s the re-invite for when the call is resumed? It MUST be a Microsoft issue!
Nope, not the case. What’s missing from that 200 OK is a=inactive, an actual acknowledgement from the provider to Skype for Business that says, “Hey, yeah, I got it and I’m on the same page! You’re putting this call on hold!” Skype for Business sends back an ACK essentially saying, “Yeah, I got your 200 OK,” but since it’s not seeing that a=inactive, it’s essentially still waiting for a proper acknowledgement that the call has been placed in inactive status. SMOKING GUN! YEAH!
Unfortunately, this SIP provider flatly refused to take any responsibility for this problem.
Well, after many hours and agonizing calls with support, we finally get at the heart of the issue (which included some teeth pulling on our end to get cooperation). The SIP provider redirects us back to AudioCodes, since this provider vaguely remembers having a client with the same issue and AudioCodes was able to fix it in a jiffy. “Funny, I talked to AudioCodes on this issue before,” I thought, but it was before we had identified exactly what the problem was. I checked with AudioCodes, and, presented with the information about the incorrect 200 OK response, they have a solution!
There’s a setting that will modify the SDP at the Mediant and actually insert the a=inactive into the returned 200 OK! Here’s where we find it:
Go to IP Profiles and choose the profile for your SIP provider and click Edit:
Choose SBC Signaling:
Now scroll down to “Remote Hold Format” and set it to “Inactive”:
That’s it. Seriously. All those hours on the phone with the various support people, all those heated arguments with the SIP provider, and it all boiled down to one single drop-down menu option. But I’ve suffered so you don’t have to.
After making the changes, we tested the calls, we see the 200 OK come from the provider without the a=inactive, but then when it’s sent from the SBC to Skype for Business, like magic, there it is! Hold now works, transfers now work, and there’s no longer an army of receptionists coming after me with pitchforks!
Thankfully it is now resolved and the client is happy and functional. This isn’t the resolution I would really have wanted as I’d prefer that the provider sent a proper 200 OK and we didn’t have to make manipulations at the SBC, but it is what it is, and now we have lessons learned.
The moral to our little story is simply this: If you are going to get a SIP provider, and you are using Skype for Business, the list of certified providers is there for a reason. Microsoft has done the homework with these guys and has gone through great lengths to make sure that they work with Skype for Business. Make use of their research and choose someone from the list. Please. It’ll do a lot for your sanity, and mine.