Publishing to Transcoder (WebRTC)

Publishing to Transcoder with WebRTC

WebRTC clients require using the Stream Manager proxy in order to publish. This essentially means that you will request to start publishing on the streammanager proxy webapp which is then transferred to the Origin and then propegated on the Edge(s). The reason is that browser vendors require WebRTC broadcasts to be served over SSL. In an autoscale environment in which Origins and Edges are spun up and down dynamically based on load, it can be unfeasible to also have certs on each of those Origins and Edges. As such, you can broadcast through the Stream Manager proxy which will be served over SSL.

Given that the response to the GET request at:


is the following:

  "serverAddress": "",
  "scope": "live",
  "name": "mystream_1"

Your initialization configuration for an RTCPublisher will look like the following (in following with the above examples):

(function (red5prosdk) {

  var publisher = new red5prosdk.RTCPublisher()
    host: 'yourstreammanager.com',
    app: 'streammanager',
    streamName: 'mystream_1',
    protocol: 'wss',
    port: 443,
    mediaConstraints: {
      audio: true,
      video: {
        width: 1280,
        height: 780
    bandwidth: {
      video: 1000
    connectionParams: {
      host: '',
      app: 'live'
  .then(function () {
  .catch(function (e) {


The above is a very basic configuration. Your webapp may need additional configurations depending on requirements and deployment.

When utilizing the Stream Manager proxy for WebRTC broadcasts, you assign the top-level configuration app property as streammanager, and provide a connectionParams object that details the endpoint to proxy to.

Additionally, note the mediaContraints object on the initialization configuration and that it defines the video contraint with the corresponding variant qualities for mystream_1 from the above examples. This will be used in access the getUserMedia of the browser client.