• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
webrtcHacks

webrtcHacks

Guides and information for WebRTC developers

  • Home
  • About
    • Chad Hart
    • Philipp Hancke
  • Subscribe
  • Contact
  • Show Search
Hide Search

Technology authentication, Brief, ephemeral auth, kamailio, sip trunk, voxbone, webrtc trunk Victor Pascual · July 3, 2014

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“}


torrey searle stylized
Voxbone VoIP Architect, Torrey Searle

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“}

Technology authentication, Brief, ephemeral auth, kamailio, sip trunk, voxbone, webrtc trunk

Related Posts

  • Chrome’s WebRTC VP9 SVC Layer Cake: Sergio Garcia Murillo & Gustavo GarciaChrome’s WebRTC VP9 SVC Layer Cake: Sergio Garcia Murillo & Gustavo Garcia
  • Optimizing video quality using Simulcast (Oscar Divorra)Optimizing video quality using Simulcast (Oscar Divorra)
  • The Big Churn – learning from real usage stats (Lasse Lumiaho and Varun Singh)The Big Churn – learning from real usage stats (Lasse Lumiaho and Varun Singh)
  • OMG WebRTC is tracking me! Or is it?OMG WebRTC is tracking me! Or is it?

RSS Feed

Reader Interactions

Comments

  1. Peter Dunkley says

    July 3, 2014 at 5:29 pm

    Thanks for the mention. It’s nice to see some of my modules used in the wild 🙂

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • Sponsored. Become a webtcHacks sponsor

Email Subscription

Subscribe to our mailing list

* indicates required

Twittering

Tweets by @webRTChacks
webrtcHacksguides and information for WebRTC developers

Footer

SITE

  • Post List
  • About
  • Contact

Categories

  • Guide
  • Other
  • Reverse-Engineering
  • Standards
  • Technology

Tags

apple Blackbox Exploration Brief camera Chrome code computer vision DataChannel debug e2ee Edge extension gateway getUserMedia ICE ims insertable streams ios ip leakage janus jitsi MCU Microsoft NAT opensource Opus ORTC Promo Q&A raspberry pi Safari SDES SDP sfu signaling simulcast standards TURN video vp8 w3c Walkthrough Web Audio webrtc-internals wireshark

Follow

  • Twitter
  • YouTube
  • GitHub
  • RSS

webrtcHacks · copyright © 2023