You should have a working chan_pjsip based Asterisk installation to start with and for purposes of this tutorial, it must be version 15.5 or greater. Either install Asterisk from your distribution's packages or preferably install Asterisk from source. Either way, there are a few modules over and above the standard ones that must be present for websockets and WebRTC to work:
- codec_opus (optional but highly recommended for high quality audio)
Technically, a client can use WebRTC over an unsecured websocket to connect to Asterisk. In practice though, most browsers will require a TLS based websocket to be used. You can use self-signed certificates to set up the Asterisk TLS server but getting browsers to accept them is tricky so if you're able, we highly recommend getting trusted certificates from an organization such as LetsEncrypt.
If you already have certificate files (certificate, key, CA certificate), whether self-signed or trusted, you can skip the rest of this section. If you need to generate a self-signed certificate, read on.
Asterisk provides a utility script, ast_tls_cert in its contrib/scripts source directory. We will use it to make a self-signed certificate authority and a server certificate for Asterisk, signed by our new authority.
From the Asterisk source directory run the following commands. You'll be prompted to set a a pass phrase for the CA key, then you'll be asked for that same pass phrase a few times. Use anything you can easily remember. The pass phrase is indicated below with "********". Replace "pbx.example.com" with your PBX's hostname or ip address. Replace "My Organization" as appropriate.
We'll use the asterisk.crt, asterisk.key and ca.crt files later.
Configure Asterisk's built-in HTTP daemon
To communicate with websocket clients, Asterisk uses its built-in HTTP daemon. Configure /etc/asterisk/http.conf as follows:
<your...> references with the paths to your certificate files. For instance, if you used the procedure above to generate a self-signed cert,
<your_cert_file> would be
Now start or restart Asterisk and make sure the TLS server is running by issuing the following CLI command:
Note that the HTTPS Server is enabled and bound to
[::]:8089 and that the
/ws URI is enabled.
If you're not already familiar with configuring Asterisk's chan_pjsip driver, visit the res_pjsip configuration page.
PJSIP WSS Transport
Although the HTTP daemon does the heavy lifting for websockets, we still need to define a basic PJSIP Transport for websockets.
PJSIP Endpoint, AOR and Auth
We now need to create the basic PJSIP objects that represent the client. In this example, we'll call the client
webrtc_client but you can use any name you like, such as an extension number. Only the minimum options needed for a working configuration are shown. NOTE: It's normal for multiple objects in pjsip.conf to have the same name as long as the types differ.
An explanation of each of these settings parameters can be found on the Asterisk 15 Configuration_res_pjsip page. Briefly:
- Declare an endpoint that references our previously-made aor and auth.
- Notify Asterisk to expect the AVPF profile (secure RTP)
- Setup the DTLS method of media encryption.
- Specify which certificate files to use for TLS negotiations with this endpoint and our verification and setup methods.
- Enable ICE support
- Tell Asterisk to send media across the same transport that we receive it from.
- Enable mux-ing of RTP and RTCP events onto the same socket.
- Place received calls from this endpoint into an Asterisk Dialplan context called "default"
- And setup codecs by first disabling all and then selectively enabling Opus (presuming that you installed the Opus codec for Asterisk as mentioned at the beginning of this tutorial), then G.711 u-law.
Restart Asterisk to pick up the changes and if you have a firewall, don't forget to allow TCP port 8089 through so your client can connect.
At this point, your WebRTC client should be able to register and make calls. If you've used self-signed certificates however, your browser may not allow the connection and because the attempt is not from a normal URI supplied by the user, the user might not even be notified that there's an issue. You may be able to get the browser to accept the certificate by visiting "https://pbx.example.com:8089/ws" directly. This will usually result in a warning from the browser and may give you the opportunity to accept the self-signed certificate and/or create an exception. If you generated your certificate from a pre-existing local Certificate Authority, you can also import that Certificate Authority's certificate into your trusted store but that procedure is beyond the scope of this document.