Real-Time UC

A Universal Communications Blog by Office Apps and Services MVP Michael LaMontagne

CloudPBX Enterprise Voice Fixes Lync Office365 Skype for Business Tips

Skype for Business Cloud Connector Edition (CCE) - Operation was unsuccessful (504 Server time-out)

Today I’m shedding light on the SIP 504 response status code while working with Skype for Business Online’s CloudPBX and Cloud Connector Edition (CCE). The “504 Server time-out” error is masked in the Skype for Business Client as “Operation was unsuccessful” during an outbound PSTN call.

Understanding this error can actually become a handy tool in an Administrator’s toolkit (more on this later!).

The key is to view the ms-diagnostics details specific to the SIP response.

Let’s look at some scenarios that cause the 504 Server time-out response:

  • CCE Edge server outage:

This will give you an ms-diagnostics message: “Failed to connect to a federated peer server”;ip-address="X.X.X.X";peer-type=“FederatedPartner”;winsock-code=“10061”;winsock-info=“The peer actively refused the connection attempt”;source=“sipfedXXX.online.lync.com”.
The IP address will be the Public IP of the CCE Edge server and the source will be the last hop before the issue, this being SIPFed within Skype for Business Online.

  • CCE Mediation server outage:

This will give you an ms-diagnostics message: “Failed to connect to a peer server”;ip-address="X.X.X.X";peer-type=“InternalServer”;winsock-code=“10061”;winsock-info=“The peer actively refused the connection attempt”;source="cce.domain.com".
The IP address will be the Private IP of the CCE Mediation server and the source will be the last hop before the issue, this being the CCE Edge server.

  • Attempting to use an onmicrosoft.com domain or a SIP domain not configured within CCE:

This will give you an ms-diagnostics message: “Cannot route From and To domains in this combination”;cause=“Possible server configuration issue”;summary=“The domain of the message that corresponds to remote peer (external) is not shared between local and remote deployments”;external-domain="domain.com";external-type=“domain-type-local”;internal-domain="domain.com";internal-type=“domain-type-local”;source=“sipfedXXX.online.lync.com”.
The domain referenced will be the CloudPBX user’s SIP domain that is not configured within CCE (onmicrosoft.com domains will never work) and the source will be the last hop before the issue, this being SIPFed within Skype for Business Online.

You might be asking yourself how could this 504 response be useful? Unfortunately, I figured this out a little too late a few weeks back.

I had opened a Microsoft Office 365 Support ticket due to an outbound calling issue. Even though I submitted the Client logs, made note the call never reached my CCE and selected CCE when creating the ticket, I was greeted with the canned response:

“We would be requiring the below mentioned logs to analyse the issue causing the problem.

  1. SIP Stack
  2. S4
  3. Mediation
  4. Inbound Routing
  5. Outbound Routing

Along with these logs we require the Client logs (Tracing Folder) as well as Cloud Connector Configuration ini File.”

I now know that if I simply just turn off my CCE and I don’t get a 504 response from the Client calling outbound, the call is not making it to SIPFed and is failing much earlier within Skype for Business Online.

Hugo-Octopress Theme | Powered by Hugo