Check out our Amazon Connect solution! Learn More

New Feature: Network vs Host Geolocation

By callstats on February 8, 2021
read

When a customer reports an issue that endusers are facing, quite often it is the enduser's device, network, or environment which is causing the issue. Most often, this typically results in the support team asking the following questions to the customer/enduser:

  • Where is the user connecting from? (to figure out if it is an urban/rural setting, if it is a crowded or shared space like a coffee shop, airport or home or office)
  • What network are they on? (to figure out if they are on mobile, wifi, vpn, or is it a fixed line? and correlate that with the bandwidth or jitter performance.)
  • What ISP are they on? (to figure out if that particular ISP has had issues in the past or benchmarking against other endusers within that ISP.)

At callstats, instead of asking those questions to the customer/enduser, we try to gather these type of information to aid the support team in answering these questions more quickly.

In this blog post we are discussing how we detect the geolocation. And further we discuss the privacy mechanisms in case you want callstats not to detect and resolve the enduser's geolocation.

All the above questions assume that we have the metadata, for example we collect the network type exposed by the browser, and use the IP address resolve the location, ISP, etc.  callstats uses two mechanisms to detect the client location, we call these methods: Network and Host Geolocation. For the privacy minded apps, both of these can be turned off.

Geolocation

Historically, callstats uses the network requests arriving on callstats to resolve the geolocation, we call this method, network geolocation. The callstats loadbalancer looks at the Internet Protocol (IP) address of the connecting enduser (client_ip_address) and performs the lookup on the geolocation database. This was the default method used by callstats, but due to recent technical upgrades, we observed that some customers and endusers could not see the client IP addresses and thus the callstats data-pipeline could not resolve the geolocation.

To assist the customers that are not seeing the network location, we implemented a complementary method, host geolocation. Host geolocation is based on discovery the host IP address using the STUN protocol . In this method, callstats creates a peerconnection to callstats STUN servers (stun.callstats.io) and detects the server-reflexive IP address and resolves that to a geolocation. 

Privacy concerns

We understand that some apps do not want resolve the geolocation and do not want callstats to store the IP address.

For network geolocation, inserting an HTTP/2 proxy between callstats and the enduser. Since callstats sees the proxy's IP address instead of the enduser, the geoIP resolves the proxy's IP address instead of the enduser's location. This effectively hides the endusers' location. The instructions for enabling this are listed in our helpcenter.

For host geolocation, you can enable or disable the host IP discovery when you initialize callstats using the `collectIP` flag. The flag means that the callstats will not discover the host's IP address. 

See example below:

var configParams = {       
     collectIP: true //enables the collection localIP address
};
callstats.initialize(AppID, AppSecret, localUserID, csInitCallback, csStatsCallback, configParams);

 

To summarise, to stop the geolocation resolution for callstats, you need to add a proxy between callstats and the enduser, and set `collectIP : false` at the endpoint.

Tags: WebRTC Monitoring, ICE, dashboard, changelog, integration