Routes available for this request but no available gateway at this point .. (PSTN Calls)

While making a PSTN call (internally or externally) via SIP trunk, calls failed to connect - with an error as below:

"Routes available for this request but no available gateway at this point"

12000; reason="Routes available for this request but no available gateway at this point"; source="FE01@mydomain.int"; appName="OutboundRouting"; OriginalPresenceState="0"; CurrentPresenceState="0"; MeInsideUser="Yes"; ConversationInitiatedBy="0"; SourceNetwork="0"; RemotePartyCanDoIM="No"

Looking at the error, one possibly can start to check to ensure that:
  • Topology is updated correctly with correct PSTN Gateways and Trunks
  • All required DNS records for PSTN Gateways are in place
  • Voice Policies, routes, and PSTN usage are configured correctly
Once the above was verified and confirmed, it required further investigation. As per Wireshark logs, the SIP trunk leg on Mediation Server is sending CANCEL REQUEST straight away. So surely, there is no issue with the supplier at Gateway end, and at this stage, it was not wise to raise it with them.


Logs in Snooper at client-side showing 503 Service Unavailable coming from Front End Server.


A similar post on this blog is suggesting to increase the FailoverTimeout value in Outbound Routing configuration on Front End Servers.

SfB Server 2015 Path: 
C:\Program Files\Skype for Business Server 2015/Server/Core/OutboundRouting.exe.config

Lync 2010 Path: 
C:\Program Files\Microsoft Lync Server 2010\Server\Core\OutboundRouting.exe.config

<configuration>
<appSettings>
<add key="FailOverTimeout" value="10000"/>
<add key="MinGwWaitingTime" value="1"/>
<add key="MaxGwWaitingTime" value="20"/>
<add key="FailuresForGatewayDown" value="10"/>
<add key="FailuresForGatewayLessPreferred" value="25"/>
<!-- Valid values are between 5 and 600 -->
<add key="HealthMonitoringInterval" value="300"/>
<!-- Valid values are between 60 and 3600 -->
<add key="GatewayStateReportingInterval" value="1800" />
</appSettings>
</configuration>
 

The above change seems to have resolved the CANCEL REQUEST issue but I didn't want to change the recommended FailoverTimeout value as there was something else causing this issue. 

As the calls we're getting failed internally as well, it was easier to assume that it cannot be due to a connectivity issue between Mediation and Edge servers. Well, it turned out to be due to connectivity issues between Mediation and Edge Servers. 

When Lync/Skype for Business Edge Servers is deployed in the environment, the Mediation Server service requires constant communication with the Edge Servers. The Mediation Server acts much like a Skype for Business client regarding Edge Server connectivity. When the Mediation Server is establishing any call, it will request Media Relay ports with the Edge Server to be ready if a remote user might be involved. Even when the call is made from an internal user, this process is still followed. If the Mediation Server cannot contact the Edge Server, the actual call might not fail but a delay in call setup time can occur. Depending on the FailoverTimeout, the call might fail to connect. 

An increase in FailoverTimeout value in OutboundRouting.exe.config might help to connect to call before FailoverTimeout (as confirmed here - Lync Mediation Server CANCEL problem). However, it may not be an ideal solution to experience delay for PSTN call connectivity. 

A common issue with call setup delays/failure is connectivity between Mediation Servers and Edge Servers. Ensure that the Mediation Server can communicate with the Edge Server on port 3478 UDP and 443 TCP for port allocation. If that network connection is not available or the Edge Servers are having issues, a delay of several seconds might be incurred at call setup time (fail to connect call). Additionally, if remote Skype for Business users are not able to make calls to the PSTN, Edge Server connectivity is a key component to analyze. 

Once the connectivity of Mediation servers with Edge servers on port TCP 443 and UDP 3478 is configured, PSTN call connectivity (internally and externally) started to work without any issue.

No comments:

Post a Comment