Displaying Network and Building Information in Call Quality Dashboard (CQD) Online


In this link we describe the schema for network and building information and how to upload it to CQD Online. In this post I wanted to include a file with some sample information and add some additional information.

In an on-premises Lync/Skype for Business deployment, the clients can be internal or external depending on whether they connect via the Edge or not. The location is written to the quality report sent by the clients and can be used when querying QoEMetrics and CQD. However in an Skype for Business Online deployments all clients are by definition external, since they all connect via the Edge. That has the implication that all clients by default are seen as Outside in CQD Online, no matter if the client was actually connected on an internal corporate network.

When you work with call quality you are interested in knowing the location of a client and whether it was using a network you can manage or a network you can't manage. The assumption being that you can only improve networks you can manage. By uploading network and building information to CQD Online you can enable CQD to determine, if the client was connect to an internal corporate/managed network or to an external/unmanaged network.

CQD use the Network and the NetworkRange to correlate the Lync/Skype for Business clients IP address to a network. When the clients sends it quality report (VQReport) to the server, it contains the actual IP address and subnet mask in use. CQD takes these two, calculates the subnet and correlates it to networks by using Network and the NetworkRange. The NetworkRange is expressed using CIDR. For example if the clients IP address is 10.1.1.15, CQD will be able to correlate that to the Lyngby Office network given the sample attached. You would also be able to see that this would fall in the Inside bucket, since the Lyngby Office network has InsideCorp = 1. Please note that if you use supernetting, you will have to specify Network and NetworkRange as your clients are configured, i.e. if you use 10.1.0.0/16 as a supernet, but your clients see 10.1.1.0/24 you need to have a record for 10.1.1.0/24 in your building information.

The file format is a tab separated text file (TSV) as described in the link above. The easiest way to generate the file is to use Excel. You can add a header line with the fields from the schema and then just add rows with the information. When you're done, save the information as "Text (tab delimited)" and using the extension *.tsv from within Excel. Remember to remove the header line from the resulting file before you upload it to CQD.

When you upload the network information you specify a date range. You can look at the date range as the validity period of the network information.

CQD will start processing the information as soon as the upload happens. You can monitor the progress by using the Tenant Health option on the gear icon. This will show you how far CQD has come in the processing. An example is shown below

To validate that CQD has used the uploaded information, look at the Server-Client Summary Report. You should now see information in the Wired Inside and/or Wifi Inside categories, as shown in the example below:

  

Thanks to Sasa and the CQD team for background information.

Building_and_Network_Sample.tsv

Comments (2)

  1. Edward Melomed says:

    But for example how you deal with situation where Federated party comes from the network range of 10.1.1.0.
    Using this design not only the calls coming from the corp network will be mapped to Lyngby office by any other calls that happen to come from the place which is using the same subnet will be considered as happening in Lyngby office.

    I might be missing something here.
    Can you please clarify.

    Jens>Federated participants will send their quality report to their own servers, so you won't have this problem.

  2. Edward Melomed says:

    I see – indeed looks like federated users reporting into their own servers.

    Maybe couple of more points to clarify.
    Following statement above " That has the implication that all clients by default are seen as Outside in CQD Online". What about P2P communication between users that are both inside the corpnet ?
    Are they are also going to be considered as external calls?

    And another question:
    Mobile clients: As they are always reported in on-prem QoE as internal ( due to the UCWA connectivity) . Would they be always considered as external? How they will get classified?
    For example if I will be making call from Starbucks that happen to map to the subnet 10.1.1.0. Will such call get classified as coming from Lyngby office ?
    Jens>You are right that you can't directly distinguish between your 10.1.1.0 subnet or someone else. Both will be put in the Inside bucket based on the uploaded subnet information. My colleague Sasa suggests that you can use other data points, such as Wired vs Wifi and SSID/BSSID names, to determine if this is indeed coming from your corporate network or from Starbucks.

    Yes, for UCWA based clients the inside vs outside distinction is not correct. In CQD On-premises you will also see that most queries/reports use the filter Stream Type = Valid. That condition filter out streams from UCWA based clients.

Skip to main content