Red5 Pro WebRTC

As of Red5 Pro release 2.0.0, Red5 Pro Server includes WebRTC support and front-end integration of the Red5 Pro HTML5 SDK.

WebRTC (Web Real-Time Communication) is supported by the Chrome, Firefox and Opera browsers on desktop. In addition, the Chrome browser on Android supports WebRTC. With iOS 11 and Mac High Sierra, Safari also supports WebRTC (older versions of MacOS and iOS will fall back to HLS). Microsoft Edge support was added with Red5 Pro Release 5.4.0. Internet Explorer does not support WebRTC.

Broadcasting/subscribing of WebRTC to WebRTC, WebRTC to HLS, WebRTC to Flash, and Flash to WebRTC are all supported.

Subscribing to a WebRTC publisher using the Red5 Pro Android or iOS SDK client is supported. In addition, subscribing with WebRTC to a stream published with Red5 Pro Android or iOS SDK client is supported.

WebRTC Broadcaster/Subscriber combinations supported, in a nutshell:

  • WebRTC <==> WebRTC
  • WebRTC <==> Flash
  • WebRTC <==> Red5 Pro iOS SDK
  • WebRTC <==> Red5 Pro Android SDK
  • WebRTC ==> HLS

Overview

WebRTC runs on the standard HTTPS port (443). To run Red5 Pro WebRTC server you need to have a valid SSL Certificate for a registered URL. Red5 Pro with SSL walks you through setting up the certificate on your server. Additionally, as with other Red5 Pro server distributions, you will need to install Java (minimum version 8.0).

If you are running the server, without an SSL cert, on your local machine or on a server:

  1. You will be able to publish/subscribe locally (between browsers).
  2. You will be able to subscribe to a stream that is being published from localhost (e.g.: http://localhost:5080/live/broadcast.jsp) from a device within the same network (pointing to the IP address of your machine, not to localhost). To subscribe from a mobile device, either via browser on Android, or via SDK client on iOS or Android, the device must be on the same Wifi network as the desktop.
  3. You will not be able to publish via a WebRTC client that is not local to the machine.
  4. Note that some browsers have become more strict and will no longer allow insecure WebRTC publishing or subscribing, even on localhost.

Installing Red5 Pro With WebRTC

We recommend running WebRTC on linux, due to CPU and memory requirements. Please see Installing Red5 Pro on an Ubuntu Linux Server

If you want to run Red5 Pro WebRTC on your Windows desktop for development purposes, you will need to install Microsoft Visual Studio redistributables if you don't have Visual Studio on your machine.

If you want to run Red5 Pro WebRTC on your MacOS desktop for development purposes, you may need to install sdl_image. From a terminal window: brew install sdl_image.

Red5 Pro WebRTC Ports

The following Inbound ports need to be open on your server/firewall for Red5 Pro features to work on a WebRTC server using SSL:

Port Description Protocol
22 SSH TCP
5080 default web access of Red5 Pro; Websockets for WebRTC TCP
443 modified https access of Red5 Pro; secure websockets for WebRTC TCP
1935 default Red5 Pro RTMP port TCP
8554 default RTSP port TCP
6262 websockets for HLS TCP
8081 websockets for WebRTC (severs earlier than 5.4.0) TCP
8083 secure websockets for WebRTC (severs earlier than 5.4.0) TCP
40000-65535 TURN/STUN/ICE port range for WebRTC UDP

Cloud Hosted Server Settings

Most hosted Virtual Machines will have a private and public IP address assigned to the instance. ICE negotiation can run into problems if the server doesn't know which is which.

Modify red5pro/conf/webrtc-plugin.properties, replacing yourpublic.ip.address.here and local.private.ip.address.here with the server's public and private IP addresses, respectively.

 # Forcing a public IP address
 #force.public.ip=yourpublic.ip.address.here

 # Forcing a private IP address
 #force.local.ip=local.private.ip.address.here

 # Configure port availability checking
 #check.port.availability=true

Red5 Pro HTML5 SDK and Examples

You can use the Red5 Pro HTML5 SDK to develop your browser-based application. The Red5 Pro HTML5 Streaming Example App contains a simple project with a number of examples that can be used for testing and reference with the Red5 Pro HTML SDK.

The app is also included as a webapp with the server release for developer testing, and can be accessed at https://<your_server_ip>/webrtcexamples/ (or http://localhost:5080/webrtcexamples/ if you are running the server locally).

You will find some more details on the Red5 Pro HTML5 SDK here.

Failover for Publish and Subscribe

The Red5 Pro broadcaster (https://yourserverurl/live/broadcast.jsp) and subscriber (https://yourserverurl/live/subscribe.jsp) use the Red5 Pro HTML5 SDK which allows for fallback player support. Our examples are programmed with the following default fallback order:

  1. WebRTC
  2. Flash (RTMP)
  3. HLS

You can force the broadcaster to publish with Flash by appending the broadcaster.jsp url with &view=rtmp (e.g.: http://localhost:5080/live/localhost?host=webrtc.red5.org&view=rtmp). You can do the same with the subscriber, but you must use the individual stream's url (e.g.: http://localhost:5080/live/viewer.jsp?host=localhoststream=stream&view=rtmp). If you want to force HLS playback you can do that for the subscriber with &view=hls (e.g.: http://localhost:5080/live/viewer.jsp?host=localhoststream=stream&view=hls).

NACK to Address Packet Dropping

As defined in the WebRTC Glossary:

NACK stands for Negative Acknowledgement. It is one of the error resiliency mechanisms in WebRTC. NACK is a way for the receiving end to indicate it hasn’t received a specific packet. A NACK message is sent over RTCP to the sender of the media, which in turn needs to decide if it will retransmit the lost packet based on its availability in its cache and its estimate to the usefulness of the retransmission (will it be possible to use it once received).

In the {red5pro}/conf/webrtc-plugin.properties file, the NACK section includes three configurable settings:

#enable nack support for subscribers.
subscriber.nacks=true

# Publisher video Nacks
# Set 'udp.reordering.video' to zero to disable publisher nacks.
# Number of packets the server will potentially queue when attempting to re-order on nacks.
udp.reordering.video=16

# Number of packets the server will potentially queue when attempting to re-order.
# Audio nacks are not fully supported on all browsers.
udp.reordering.audio=2

Video NACK Details

Set udp.reordering.video to zero to disable publisher nacks.

As packets arrive, the server will check for continuity of the sequence numbers.

If there is a gap, and the queue size is less than ½ of udp.reordering.video, the server will wait for possible out of order reception.

If there is a gap, and the queue size is greater than ½ of udp.reordering.video, the server will NACK the missing packets in the gap.

If there is a gap and the queue size is greater than udp.reordering.video, the server will report lost packet in the log. Decoder state is lost, the server will issue a request to the publisher for a new key frame, and video will freeze until the key frame is received.

Audio NACK Details

Browsers did not respond to audio nacks. It is disabled in Chrome by default.

As packets arrive, the server will check for continuity of the sequence numbers.

If there is a gap, and the queue size is less than udp.reordering.audio, the server will wait for possible out of order reception.

If there is a gap, and the queue size is greater than udp.reordering.audio, the server will NACK the missing packets in the gap.

Common WebRTC Terms

Definitions below are taken from the webrtcglossary. Click the links to see the full definitions. You can also find other terms there.

  • DTLS - stands for Datagram Transport Layer Security. Simply put, DTLS is UDP + security.
  • ICE - ICE stands for Interactive Connectivity Establishment. It is a standard method of NAT traversal used in WebRTC.
  • NACK stands for Negative Acknowledgement. It is one of the error resiliency mechanisms in WebRTC.
  • PLI - PLI stands for Picture Loss Indication. It is one of the error resiliency mechanisms in WebRTC. A PLI can be sent when the receiver of the media lost a full frame or more.
  • STUN - STUN stands for Session Traversal Utilities for NAT.
  • SDP - SDP stands for Session Description Protocol.
  • TURN - TURN stands for Traversal Using Relays around NAT.
  • WebRTC - WebRTC stands for Web Real Time Communications. It is at the intersection between the internet and telecommunications.
  • WebSocket - WebSocket provides a bidirectional mechanism between web browsers and web servers for sending messages. As opposed to HTTP, where only the client can send a request to the server; WebSocket enables each side in the connection to send messages without any need to wait for past responses.

Troubleshooting

Test Supported Resolutions for your WebCam

Here's a very handly link to test what resolutions your webcam supports: webrtchacks.github.io/WebRTC-Camera-Resolution/

WebRTC Internals - browser diagnostics

This will show you more details on your WebRTC connection, and can help to troubleshoot any issues.

How to Select WebCam in WebRTC (Chrome)

Firefox will prompt you for permissions to access the camera/microphone - at which time you can select your preferred webcam. In Chrome, you will need to select which camera to use via the camera icon in the address bar.

chromecamera

Cloud Hosted Server Settings (see above)