OK, so that’s not entirely the truth – but the great Scott Hanselman says you need to have a catchy title to get ’em in.
*IF* however, you implement M:N Routing in Lync 2013 and change the trunk name so that it’s no longer the same as the gateway’s FQDN, you’ll no longer be able to call a Cs-AnalogDevice that uses that PSTN/trunk gateway:
“Call was not completed or has ended. When contacting your support team, reference error ID 503 (source ID 241).”
Snooper reports it thus:
“SIP/2.0 503 Service Unavailable”. “Analog device configured on an unknown gateway”
This will Work:
The trunk name = the FQDN of the Gateway.
This will break it 100% every time:
PSS is working on the case. They’ve been able to dupe it, so we’re just in the queue for a fix. Stay tuned.
Credit where it’s due – my colleage Dan nailed this one. I’m just the messenger. Thanks Dan!
Thanks for sharing this. It’s been several months since this was discovered. Is it still broken in the latest CU? Have any workarounds (aside from renaming your trunk) been identified?
Hi Hugh, yep, still broken. I’ve just mailed the Service Manager I was dealing with at the time asking if he has any update on it.
Hi there
Any update or workaround?
Best regards
Henrik
Hi Henrik, alas no update, and nothing coming back from the support people at Wipro.
The work-around is as above – just keep the trunk name the same as the FQDN of the g/w.
Just fallen in this hole with SfB 2015 CU3, wasted a good few hours trying to work out how I’d broken the Analogue devices. Found this article an voila, going again. I have cheated and added the gateways using an alias which I now also use on the analogue device.
Grrr, I had forgotten why this work around was in place and was trying to remove is from the topology.
Anyway, I can confirm that the issue still exists with CU4.
I just ran into this very same issue – still cactus :D
What are the chances of getting all the trunks renamed?
That’s easily enough done. I was doing the trunk naming hokey-pokey when I was working with PSS on confirming the fault.
Another approach some of my colleagues have taken is to enable the Mediation Server for TCP, and create the same PSTN Gateway AGAIN in the topo – this time talking to it over TCP device using its IP address. (This is how you can fool Topology Builder to let you add the same Gateway twice). You then add the Gateway’s IP as the one for your CsAnalogDevice. Problem solved (albeit in a slightly cumbersome way).
Just ran into this out in the middle of frikken no-where.. Thanks Grieg for the heads up!
Will the scenario change if there are multiple Trunks on the same Gateway? Or is it the case that if the Root Trunk has the same FQDN then it will work?
Hi Michael. Alas it’s a case of “the more the miserabler”. Yes, if one trunk shares the same FQDN as the Gateway you’re good to use it for your analogs, but if you try to use any of the extra ones as the -gateway for a CsAnalogDevice you’ll encounter the same situation documented above.
– G.
Just like to point out this bug still existing in Skype4b 2019.