C.2. RTC:engine enabling

C.2.1. Enabling services via CLI
C.2.2. Enabling via Panel for resellers and subscribers
C.2.3. Create RTC:engine session
C.2.3.1. Create sessions
C.2.3.2. Receive sessions

The RTC:engine is not activated by default and needs a few steps to setup.

C.2.1. Enabling services via CLI

First you have to enable it first on your server via CLI. Connect with SSH on your server, open /etc/ngcp-config/config.yml with your editor of choice and change the following properties:

fileshare:
  enable: yes

rtcengine:
  conference:
    relay:
      app_id: bormuth
      url: http://xms.sipwise.com:81
    call:
      relay:
      app_id: bormuth
      url: http://xms.sipwise.com:81
  enable: yes
  expose_provisioning_api: yes

www_admin:
  http_csc:
  servername: '$IP_OF_VM'

Save the config.yml file and run $ ngcpcfg apply enable rtcengine. After the script ran, check the status of all services via $ monit summary or $ monit status.

C.2.2. Enabling via Panel for resellers and subscribers

The WebRTC subscriber is just a normal subscriber which has just a different configuration in his Preferences. You need to change the following preferences under Subscribers→Details→Preferences→NAT and Media Flow Control:

  • use_rtpproxy: Always with rtpproxy as additional ICE candidate
  • transport_protocol: RTP/SAVPF (encrypted SRTP with RTCP feedback)

The transport_protocol setting may change, depending on your WebRTC client/browser configuration. Supported protocols are the following:

  • Transparent (Pass through using the client’s transport protocol)
  • RTP/AVP (Plain RTP)
  • RTP/SAVP (encrypted SRTP)
  • RTP/AVPF (RTP with RTCP feedback)
  • RTP/SAVPF (encrypted SRTP with RTCP feedback)
  • UDP/TLS/RTP/SAVP (Encrypted SRTP using DTLS)
  • UDP/TLS/RTP/SAVPF (Encrypted SRTP using DTLS with RTCP feedback)
[Warning]

The below configuration is enough to handle a WebRTC client/browser. As mentioned, you may need to tune a little bit your transport_protocol configuration, depending on your client/browser settings.

In order to have a bridge between normal SIP clients (using plain RTP for example) and WebRTC client, the normal SIP clients' preferences have to have the following configuration:

transport_protocol: RTP/AVP (Plain RTP)

This will teach Sip Provider to translate between Plain RTP and RTP/SAVPF when you have calls between normal SIP clients and WebRTC clients.

C.2.3. Create RTC:engine session

C.2.3.1. Create sessions

Request:

curl -i -X POST --insecure --user SUBSCRIBER_ID:SUBSCRIBER_PW -H 'Content-Type: application/json' --data-binary '{}' https://IP_OF_VM/api/rtcsessions/

Response Header:

Location: /api/rtcsessions/7
C.2.3.2. Receive sessions

Request:

curl -i -X GET --insecure --user SUBSCRIBER_ID:SUBSCRIBER_PW -H 'Content-Type: application/json' https://IP_OF_VM/api/rtcsessions/{ID_FROM_LAST_REQUEST_HEADER}

Response Header:

{
  ...
  "rtc_app_name" : "default_default_app",
  "rtc_browser_token" : "22fz8e51-ad6e-481e-a389-15c58c3fe5ac",
  "rtc_network_tag" : "",
  "subscriber_id" : "263"
}
[Tip]

Use rtc_browser_token in your cdk.Client.