As part of ongoing expansion we recently added another DDI range. Most of the new range would be dormant initially. Of course I wanted to catch all the calls that were unassigned and send them off to a RGS.

Here is where the plot thickens…
This seemed to work well in Lync 2010, now I find myself on 2013 and see a few interesting new features…like trunk-to-trunk routing.

So I ring the unassigned number and low and behold, the gateway sends the call to Lync. Lync sees the number as unassigned and does a trunk-to-trunk transfer sending the call back to the gateway. You know the rest of it right, the gateway sends the call to the Telco who sends the call back to the gateway and then back to Lync and before we know it all the SIP channels between Lync and the gateway are saturated.

The caller simply hears what seems to be a longer than usual set up time and then the call fails.

So by now I am thinking why isnt my unassigned number config working…
A similar issue on Technet leads me to believe that the issue is resolved in Lync 2013 July here 

Not in my case though…

Further down the same Technet page I came across a reference to Chris Norman’s article on Call Park retrieval Issues here (nice article Chris!)

I also came across this blog http://d1it.wordpress.com/2013/05/14/pstn-to-lync-2013-unassigned-number/ (again nice work MLamontagne)

Turns out the gist of the matter is that the trunk-to-trunk transfer is engaging prior to the call reaching the Unassigned number config.


The SolutionAs per Chris’ findings, removing all the PSTN Usage records from the Trunk configuration which in effect prevents the Trunk-to-Trunk transfer from engaging.

If you needed Trunk-to-trunk routing a separate route should be built for the purpose.

Removed the PSTN usages from the route, and voila!

Microsoft has apparently addressed this issue in the Lync 2013 July Cumulative Update, I can confirm that this update DID NOT do it for me.