The full error is this:
ms-diagnostics: 3169;reason=”The meeting id to resolve has unneccessary padding on the id component.”;meeting-id=”42666530″;source=”medserv1.flinchbot.com”
So where did that error come from?
We use a global ITSP to provide us with local dial in conferencing numbers. So while we don’t have a Lync installation in – let’s go with Latvia – we can still provide a local dial in conferencing number. It’s a pretty cool little feature we rolled out. The ITSP we use doesn’t actually have any lines in Latvia. They just contract with a local carrier, convert the call to IP, then ship it over to one of their location in London or New York where it then connects to our Mediation servers via a SIP trunk.
This all works really well. Except for the times when the carriers do updates and don’t inform the ITSP. And then some of our Dial In Conferencing features fail.
We got a ticket early this week that most users were unable to join Lync meetings by dialing into one of those global numbers and punching in their meeting ID. For sake of keeping this simple, let’s say it was calls to the number in Latvia. Lync answered the call just fine and prompted them to enter their meeting ID. But more often than not, it came back with the “I’m sorry. I can’t find a meeting with that ID” message.
But we were typing in the number correctly. I figured it had to be an issue local to Latvia as no one reported issues when calling the numbers in Slovenia or Hungary or Czech Republic, etc. I opened a ticket with the ITSP and began some Lync logging to see if I could narrow down the issue.
As part of logging, I came across the message above. There are two things that piqued my interest:
- I will bet a million dollars that I entered the Meeting ID correctly. But in the log message, the Meeting ID is wrong! It has an extra 6. The real meeting ID value is 4266530 and not 42666530.
- And that verbiage about “unnecessary padding”. What does that mean? That’s not an option in Lync that I know of. I can’t just type Set-CsVoiceRoute -UnnecessaryPadding $False to fix this.But it feels like a DTMF issue. And if there is one thing I’ve learned about IT and troubleshooting, it’s all about the feels.
Along with a few other things, this seemed to be a pretty obvious issue with the passing of DTMF tones (As a reminder, DTMF stands for dual tone multi frequency which I guarantee I forgot.) Google provides no value when Googling “DTMF Padding” and Bing isn’t any better (the first hit was for an iOS app.) So I have no idea what padding really means but to me it was confirmation that DTMF wasn’t being sent correctly to Lync.
After many hours (over night, actually) we got a response from the ITSP that the carrier had recently applied “an in-band DTMF patch conforming to RFC2833…The issue was the delay difference between receiving and re-transmitting the DTMF’s. Sot some calls the expected interval was smaller due to carrier interconnect timers…“.
So that “delay difference” is probably what Lync calls “unnecessary padding”.
Anyway, the carrier did something on their end and the problem was solved.