We’d two (2) offices physically located at two (2) different countries – SG & MY. A small scale call center is setup within the MY site to undertake Technical Support calls from locally & SG. Nonetheless, this Small Scale Call Center underlying is powered by Lync Server 2013 and Sonus UX1000 Media Gateway.
To give a better visualization of the setup, the layout looks like this:
Recently, the customer from SG site had given feedback that Inbound calls to the Call Center (+656212000) couldn’t get through, where calls are eventually dropped after a single ring tone.
However, calls to other SIP users (e.g. +6562120001) still works where the targeted SIP users’ Lync Client/Phone rings when an Inbound call is made. To investigate this, I’d lay down a few possibilities: The TDM-PBX, Media Gateway or the Enterprise Voice number could have been duplicated.
To start off, I’d to reproduced the issue by making an Inbound call and collect Traces from the Sonus Media Gateway & Mediation Server (which is Collocated with the Front-End Pool Server). Outcome from using Sonus Log Exchange (LX):
At the first 3 column indicates the calls is being attempted, from my mobile number of 60163735109 to the Call Center number (+65)6212000 and it seems that the signaling is working where the PBX throws the signal to Sonus UX1000 for processing. After which the Media Gateway will need to parse this signal to the Lync Mediation Server role. Further drilling into the log indicates that the Object/Resource wasn’t available:
At the Lync Server, using the options selected on Mediation Server, S4 & SIP Stack:
As the RGS Service was created under the MY’s Pool Server, the seems to have rejected the call, returning the message back to the UX1000 which caused the message of unavailable to be thrown back:
ms-diagnostics: 1038;reason=”Failed to connect to a peer server”;fqdn=”myfe.child.mydomain.com”;peer-type=”InternalServer”;winsock-code=”10061″;winsock-info=”The peer actively refused the connection attempt”;source=”myfe.child.mydomain.com”
During that moment, I thought of the most simplest method to resolve this issue is to recreate the entire RSG object as it was a weekend; so I went ahead to delete the Workflow, Queue & Group in sequences, when removing the object in Queue, there was a warning message that caught my attention:
I ran the command of the DFS Share: \\Child.MyDomain.com\MY-LyncP1F1\ and the folder returned empty, this is when I notice that my DFS mapping could’ve been removed “unintentionally” by another Administrator. To resolve this matter, I’d just to make sure that the correct shared path/directory is also configured under the DFS Management. For pre-caution, I republished the Topology Builder to make sure that the DFS path can be read by my Pool Servers.
Next, I’ve re-created the RSG services and all services had immediately came back online; the RSG folders & objects are also populated onto the File Store without any errors. To make sure that the RGS Service are working, another call was made from my mobile and the calls was routed based on the configured Workflow & Queues.
Conclusion: the RGS objects in the File Store are required to be accessibility as part of the reference when calls are being made, else calls will be dropped: