http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1
1. Tutorial Overview
WebSocket is a protocol that provides full-duplex communication between web clients and servers over TCP connections. Using the WebSocket protocol, browsers can connect to web servers and exchange data, regardless the type or nature of the application protocol. RFC 7118 leveraged this protocol in order to allow browsers to make VoIP calls using the SIP protocol.
This document describes how to use OpenSIPS as the core component of a SIP platform that connects both SIP clients (over UDP, TCP or TLS) as well as browser based clients (using SIP over WebSockets). While OpenSIPS handles the SIP signalling part, media is handled by RTPengine, a high performance media proxy that is able to handle both RTP and SRTP media streams, as well as bridging between them.
This tutorial is inspired from
2. Setup
2.1 RTPengine
Installation
The RTPengine consists of two main components: a kernel module used to efficiently route the RTP packets directly in kernel, and a daemon used to communicate with OpenSIPS. You can find more details here. Both components can be installed from debs (on Debian based systems) or directly from sources. Simply follow the official documentation to install RTPengine.
Usage
After installing the kernel module and the additional libraries, the rtpengine daemon has to be configured. This can be done from /etc/default/ngcp-rtpengine-daemon if installed from debs, or from the command line if the daemon is started manually. On systemd based OSes, Eric Tamme created some startup scripts.
The interesting parameters we are using are as follows:
-i: the listening interface for RTP/SRTP-n: the listening IP and port that is used by OpenSIPS to communicate with the RTPengine (NOTE: the rtpengine module only works with the rtpengine NG protocol, so you must use-n/--listen-ng; Using-u/--listen-udpor-l/--listen-tcpwill not work!)-c: the IP and port of the CLI - this is used to gather statistics for the RTP/SRTP sessions-m, -M: both take an integer as argument and together define the local port range from which rtpengine will allocate UDP ports for media traffic relay. Default to 30000 and 40000 respectively.-L: indicates the debugging level
You can find all the parameters available here.
Here is an example that runs rtpengine from cli that talks with OpenSIPS over localhost and RTP using the 1.1.1.1 IP:
./rtpengine -p /var/run/rtpengine.pid -i eth0/1.1.1.1 -n 127.0.0.1:60000 -c 127.0.0.1:60001 -m 50000 -M 55000 -E -L 7
Troubleshoot
First make sure the rtpengine daemon is started:
ps -ef | grep rtpengine
If the rtpengine daemon does not start, make sure the xt_RTPENGINE kernel module is loaded:
lsmod | grep xt_RTPENGINE
If the module is not loaded, make sure the ip_tables and x_tables kernel modules are loaded. Also, check the logs for the last errors of the system
dmesg
2.2 OpenSIPS
In order to use WebSocket in OpenSIPS, one has to load the proto_ws into its configuration file and define a listener for the WebSocket protocol.
listen=ws:127.0.0.1:8080 ... loadmodule "proto_ws.so"
Next, the rtpengine module has to be loaded and configured to communicate with the rtpengine daemon.
loadmodule "rtpengine.so"
modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:60000")
Note that the rtpengine_sock parameter should be the same as the -n parameter sent to the rtpengine daemon, and OpenSIPS should have IP connectivity to that socket.
Next, the routing logic has to be changed in order to treat different the clients that use DTLS-SRTP, from the ones that use plain RTP and enable bridging if necessary. To do that, one can check if the request message was received over the WebSocket protocol. This can be achieved using the following code:
if (proto == WS)
setflag(SRC_WS);
In case the request is a REGISTER, we want to store this information in the location table, so that we know then the user is called. To do that, we can set a branch flag before calling the save()function. This way, when the lookup() method returns, we will be able to determine whether the client uses WebSocket or not.
if (is_method("REGISTER")) {
if (isflagset(SRC_WS))
setbflag(DST_WS);
fix_nated_register();
if (!save("location"))
sl_reply_error();
exit;
}
When a call is placed, based on the two flags (STR_WS and DST_WS) we can determine what our caller and callee can "speak" (either RTP or DTLS-SRTP) and instruct the rtpengine daemon how to handle the call. We can do that by tuning the parameters passed to the rtpengine_offer() function.
if (isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "ICE=force-relay DTLS=passive";
else if (isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
else if (!isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "UDP/TLS/RTP/SAVPF ICE=force";
else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
rtpengine_offer("$var(rtpengine_flags)");
The rtpengine_answer() function logic should look like this:
if (isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "ICE=force-relay DTLS=passive";
else if (isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "UDP/TLS/RTP/SAVPF ICE=force";
else if (!isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
rtpengine_answer("$var(rtpengine_flags)");
Now, all we have to do is to close the RTP/SRTP session when the call is ended. To do that, we use the rtpengine_delete() function:
if (is_method("BYE|CANCEL")) {
rtpengine_delete();
Having done all these settings should provide a full setup for interconnecting SIP clients over both UDP, TCP, etc. protocols, as well as browser based SIP clients over WebSocket.