Trunking WebRTC: the user authentication challenge (Torrey Searle)

We probably talk about existing telephony stuff too much here, but the reality is there are billions of phone about there that want to be connected to the web like nearly everything else. This is especially important for any business that wants to link its website with its internal phone system.

If you are a modern enterprise or contact center, odds are you connect your phone system to the PSTN using a SIP trunk. This approach is light years ahead of previous technologies, but what about allowing callers to come in from the web with WebRTC? Often this means buying your own gateway or connecting your website to a hosted API provider. Is there something like a WebRTC trunk?

Wholesale trunking provider Voxbone recently announced a different solution to this problem – they’ll take your WebRTC calls and route them over a SIP trunks. We asked Voxbone’s Senior VoIP Architect, Torrey Searle to tell us how they put this service together.

{“intro-by”:”chad“}

---

Voxbone is a wholesale provider of telephone numbers.  We recognize the future of communications also means making calls from the web with WebRTC. To enable web calling, we are currently beta testing a solution that allows our customers, often enterprises and contact centers,  to reach numbers that they own via WebRTC and receive it on their existing SIP trunk.

Architecture

To Support WebRTC, we decided to add a Kamailio Gateway on our network as a secure entry point to our network.  Kamailio is an ideal candidate for access control due to its rich collection of Denial of Service (DOS) protection modules, SIP sanity checking modules, and it’s high performance.   For ease of integration, we use SIP over WebSockets using JsSIP.  We customized our JsSIP library to allow it to respond to Session-Timer refreshes so our network can better detect when a web browser “disappears”

Ephemeral Authentication

One of the biggest challenges of developing a wholesale solution for WebRTC is the issue of Authentication.  We don’t own the website our customers develop, and we don’t have any relationship with the end-user of our Customer, so unlike calls from the PSTN, we cannot be sure of where the call will come from.  So here is the challenge: How do we know that the WebRTC call is one that our Customer wants?

An idea for how to address this came a year ago when Peter Dunkley presented his  Ephemeral Authentication Module for Kamailio.  This concept is based on Justin Uberti’s Internet Draft for Ephemeral Authentication for TURN.  The idea is simple:  two servers that  trust each other have a shared secret.  The first server creates a temporary login in the form of timestamp:username and hashes it against the shared secret to form the corresponding password, this secret is given to the end user, who uses it to log into the 2nd server.  This second server performs the same hashing procedure and see if the password matches.  If it matches, it knows that the end-user has been “trusted” by the first server.  Additionally, since there is a timestamp encoded in the login, the timestamp can be checked and old timestamps rejected, making these logins time limited and “disposable”.

So how does this help? We use this mechanism twice:

1. The first time, it’s used to identify that the call originates from our customer’s website. We allow our customers to provision a shared secret on our customer portal.
2. Then we provide the customer with a basic auth servlet to generate ephemeral authentication tokens to embed in their web page that can be consumed by our hosted auth service.

Application

Using this mechanism, we can securely know that the browser is coming from the customers website.  The customer in turn can choose to lock down access to his hosted web servlet as he wishes.

However this is not sufficient without the second step.  Our Kamailio – the secure entry point into our network – knows nothing of our customers by design. Since the Kamailio instance is publicly reachable, we need to let it know we’ve authenticated that the call originates from a trusted party. This is where we use the mechanism a second time.   Our auth service also has a shared secret between itself and our Kamailio Servers.  When the Voxbone web service consumes the ephemeral authentication token from the customer, it sends an ephemeral authentication token for Kamailio in the response.

In conclusion, by creating a chain of trust between our customer’s end user and our network, we are able to securely establish a relationship between the end-user and our direct customers.

Our web servlet has been made available as open source.  Check it out at Voxbone’s GitHub repository.

{“author”, “Torrey Searle“}