Skype for Business Online - Cloud PBX, PSTN Calling and Audio & Video troubleshooting

Technical Level : Expert


PSTN calling is an add-on telephone service that, when combined with Skype for Business Cloud PBX, can become your phone system. PSTN calling provides the people in your business with a primary phone number, and lets them make and receive phone calls outside of your organization

Users who are assigned phone numbers can make voice calls from all Skype for Business devices, including desktop phones, PCs, and mobile devices. They can control their calls through desktop phones, for example, mute/unmute, hold/resume, transfer calls, and use call forwarding features.

More info here

Before raising a support request with Microsoft there are several information that can be reviewed and collected to better understand the issue and lead to a faster solution.

The questions for media will always guide you to finding the easiest two points to test with. 

It is understandable that some scenarios cannot be broken down to a simple two points. 

However if you can simplify the scenario it will greatly increase your odds of resolving the issue faster.



Understand the issue and check if the problem can be reproduced on demand.

Some examples of what might be provided by your users:

  • Unable to call each other
  • Unable to join audio in federated meetings
  • Audio works externally but desktop sharing is failing

Audio & Video Scenario

  1. What client version are you running?
    • Skype for Business
    • Lync 2013
    • 3rd Party Endpoint
  2. What type of client are you running?
    • Desktop
    • LRS
    • Mobility
    • Lync Phone Edition
    • Teleconference (Polycom, Cisco, ...)
  3. What type of call is being attempted
    • Internal to External
    • Internal to Internal
    • External to External
    • Federated Call
    • PSTN
  4. If it's a PSTN call 
    • Where is the user located?
      • If it fails when the user is external does it work for internal users?
    • What number is being dialed?
      • Do all numbers fail?
    • What is failing for the user, making or receiving calls?
    • Is there any specific error being returned when the call fails?
    • Is there a certain Gateway which experiences the issue or does it occur on all gateways?
  5. The scenarios that relate to P2P in the same organization will allow following a similar line of questions.
    • Is there an HLB in front of the Edge Servers (Internal or External Interfaces)
    • Is there firewalls between the users and Edge Servers
    • Has this ever worked?
    • If this was working prior are you aware of any changes when this stopped?
    • Are you aware of any conditions in your network that could be adding to this issue?
  6. The Federated call scenario will get more involved depending on where the failures could be occurring.
    • Does it matter who starts the conference?
      • Meaning are you failing to join the Federated partners meeting, but they are able to join yours?
    • Does it matter where your endpoints are physically located?
      • If you join from internal or external does the experience change?
    • Has this ever worked?
    • If this was working prior are you aware of any changes when this stopped?
    • Are you able to join other Federated meetings with another partner?

Please also check Media Quality and Network Connectivity Performance in Skype for Business Online article


  • Turn on error logs (full logging) in Skype for Business client
  • Reproduce the issue
    • Note the SIP addresses involved to be easier to identify the call with the issue
    • Collect SIP URI of the two users involved or PSTN number. if they are joining a meeting get the meeting ID/URL

  • Review the collected .uccapilog file with Snooper from Skype for Business Debug Tools or with TextAnalysisTool.NET
    • Select the messages tab to review only the SIP messages

  • In many call setup scenarios the issue is dependent upon the location of the user, so it is important to understand if the user is signed in internally or externally. Check this by searching the .uccapilog for the following:
    •  ms-user-logon-data
    • If this header exists it will appear with a remote user tag on it which indicates the client is signed in externally (through the Edge), and if no header exists with a remote user tag (i.e. no search results returned) then the user is signed in internally.
  • During call establishment for media there is SDP (Session Description Protocol) information that will be in the SIP data.
    Depending on the type of media that was being attempted (audio/video/desktop sharing/file transfer) there are some search parameters that will help to find the call where the issue was reproduced.
    These parameters will search for the media line (m=) for the appropriate media type:

  •  Audio Call m=audio
  •  Video Call m=video
  •  Desktop Sharing Call/ m=applicationsharing
  •  Application Sharing Call
  •  File Transfer Call m=data
  •  Instant Message Call m=message

  • Using the above table search for the appropriate media line (m=) to find the call where the issue was reproduced.
    Finding the other user involved and using timestamps to validate the timeframe of the issue will best zero in on the call where the issue actually occurred. Once the call is located, right click on the INVITE and select the option "Find Related," to find the related SIP packets for the call where the issue reproduced.

  • Review the candidates provided by both sides of the call (typically the two users involved but can be a user and a server depending on the scenario).
    To do this review the SDP information within the INVITE for the calling user and the 183 Session Progress/200 OK for the recipient user.
    When reviewing the SDP it is easier to read the ICEv19 candidates rather than the ICEv6 candidates. : 
    •  Content-Type: application/sdp
       Content-Transfer-Encoding: 7bit
       Content-ID: <*** Email address is removed for privacy ***>
      Content-Disposition: session; handling=optional; ms-proxy-2007fallback

  • Versus the same candidates in ICEv19: 
    •  Content-Type: application/sdp
       Content-Transfer-Encoding: 7bit
       Content-ID: <*** Email address is removed for privacy ***>
      Content-Disposition: session; handling=optional

  • Candidate analysis. There are multiple key points to look for when analyzing the resulting candidate sets for a call, but what to look for varies by media type. Audio and video calls will provide both UDP and TCP candidates, however, both modalities will prefer to settle on UDP candidates as the final option when they actually connect media. Desktop/application sharing and peer-to-peer file transfer are only able to use TCP candidates and therefore they will only provide TCP candidates as options in the SDP (there will be no UDP candidates offered for these modalities).

  • Candidates will appear as pairs of ports (one for RTP and one for RTCP) or as a single port for RTP and a pair is denoted by the first number listed in the candidate attribute line (a= line).

  • Additionally, each candidate has a typ value that denotes which type of candidate is listed. The common types are host, relay, and srflx (server reflexive):
    • host -> Candidate provided by the host system (the client system's IP address)
    • relay -> Candidate provided for relay purposes by the Edge server
    • srflx -> Candidate provided by the Edge server that is an attempt to discover the public IP of the client system (this is useful in scenarios where users are external but behind a NAT still).

  • When call setup fails due to media negotiation, there is often an issue obtaining relay candidates as clients are commonly not on the same network, and therefore, not able to communicate directly.

  • In the UccApilog examine the BYE message for the call that failed. Specifically in the BYE there will be a ms-client-diagnostics header with an error description for what failed. Additionally, there will be an ICEWARN inside the same BYE message which will indicate if there were any issues with candidates. Use the  ICEWarn Tool to determine some of the possible causes of problems during media negotiation.

  • After both parties have a full candidate set if the call is still not completing then the best option is UccApilogs and network traces at all involved locations:
    • UccApilog from one of the two the client systems.
    • Network trace from both of the client systems.
    • Network trace(s) from the Edge server(s) involved.

  • Once the network trace data is collected it will need to be analyzed to determine why the two clients are unable to communicate with each other. The first step is utilizing the UccApilog to determine the ports involved in the conversation so that the network traces can be filtered effectively to determine how the call is failing to establish. After pulling the port information from the UccApilog then create filters for the network traces to use like below:
    •  udp.port==X || udp.port==Y      //Client A
    •  udp.port==M || udp.port==N    //Client B

  • This can be further refined to look at only a single direction at a time using filters like:
    •  udp.srcport==X
    •  udp.dstport==X

  • These type of filters will show traffic going from client A to B or client B to A respectively in each trace, but since there are multiple candidate pairs during the negotiation process there will likely be a need to review this for multiple candidates
  • Additionally, tracking these same candidates as packets flow through servers is essential to isolating issues with traffic to/from Edge servers. Usually, once it gets to the point where the issue is with media setup and network traces are collected the issue tends to be with a device on the network, and it is a matter of finding that problem to assist your network team.

*** Email address is removed for privacy ***

*** Email address is removed for privacy ***


Forum Article Info

Last updated April 24, 2020 Views 1,084 Applies to: