Publishing Topology Completed with Errors - Microsoft.Rtc.Applications.TestBot

Issue
Publishing Topology Completed with Errors - Microsoft.Rtc.Applications.TestBot

What is Testbot?
Testbot is the little fella that runs the Audio Test Service

You can see TestBot SIP Address woth the Lync Server Management Shell command:
Get-CSAudioTestServiceApplication

OwnerUrn: urn:application:testbot
SipAddress: sip:RtcApplication-0e0e407a-6283-4c93-99fa-c0e252b8af09@lynclab.local

OK so that has also revealed the problem in my case, the SIP domain was renamed from .local to .com and it seems that TestBot now has an invalid SIP address.

Probably would have noticed other issues had I tried using the Audio TEst Service as that SIP address would be unreachable.

Solution
We will need to correct the TestBot SIP address in ADSIEdit.
Using the SIP address identity (from  Get-CSAudioTestServiceApplication) we can search for the object.

Identity: CN={0e0e407a-6283-4c93-99fa-c0e252b8af09},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=local

1. Open the ADSI Editor.
2. Right click ADSI Edit and select Connect To, and then select Configuration from the "Select a well known Naming Context list" and click ok.
3. Click on node CN={46577062-9cae-404b-b89c-a3d39511e4cc}, CN=Application Contacts, CN=RTC Service, CN=Service, CN=Configuration, DC=lynclab, DC=local, and then right click this node and then select properties.
4. Choose the msRTCSIP-PrimaryUserAddress attributes, and change the domain part of value to: sip:RtcApplication-0e0e407a-6283-4c93-99fa-c0e252b8af09@lynclab.com
5. Log on to your Lync front end server and restart Audio Test Service. Once the service has been restarted, try a test call from Lync client.

You should no longer have issues publishing the Topology either.

NOTE
The CN attributes, GUID's and domain names used are from my Lab so please replace with your own.

Call loop between Lync and Gateway

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 Solution As 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!