Toggle navigation

Real-Time Collaboration Service Configuration

Our Atlassian server apps include a built-in, behind the firewall real-time collaboration service (RTC) that allows multiple users to work on the same project, at the same time. This documentation is to help administrators get set up, and potentially help them solve problems with it.

Configuring RTC on Your Server

You'll find the the Real-Time Collaboration Service settings in your Balsamiq Wireframes configuration panel.

There is a good chance (especially if your users have a direct connection to your server) that the RTC service will just be working, and you won't have to make any changes.

However, in the event that you are using a reverse proxy or multi-node configuration with your Atlassian Server, you will have to make some tweaks to the settings to allow RTC to function.

Reverse Proxy Configuration

Configuring RTC to work with your reverse proxy can be done in the *Advanced Settings portion of the configuration panel. You'll want to make sure the protocol matches your server's setup, as well as the proxy port.

Multi-Node Cluster with Reverse Proxy (Data Center Installations)

If you're running a multi-node server cluster with a reverse proxy, you will need to use the Multi Nodes Configuration section of the configuration panel to specify your redis hostname and port.

Reverse Proxy Examples

Here are some examples of common server environments and what you would need to do to get RTC working in them.

location /jira {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 100M;
        add_header "X-UA-Compatible" "IE=11" always;

location /rtc.jira {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:9093/rtc.jira;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

One listener on port 443 (terminating SSL):

You'll need one rule for the main application and one for the RTC path, forwarding to two different targets.

The RTC heathcheck is on the standard Atlassian port, but the RTC port will be the default backend RTC port (9083 in Confluence, for example).

#add X-Forwarded-For headers
   option forwardfor

frontend HTTPS
   bind :443 ssl crt /etc/ssl/private/haproxy.pem
    acl acl_rtc url_beg /
    use_backend bk_j_rtc if acl_rtc
    default_backend bk_j

backend bk_j
   server s1 <ip_or_hostname>:8080

backend bk_j_rtc
   server s1 <ip_or_hostname>:9093
# server <server_name> <tomcatFQDN__or__tomcatStaticIP>:<Rtc_port>
Apache 2.4

You will need to enable the following Apache modules (if they are not already enabled)

  • mod_proxy
  • mod_proxy_http
  • proxy_wstunnel
  • mod_rewrite
ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Require all granted

  ProxyPass "/" "http://localhost:9093/"
  RewriteEngine on
  RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
  RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
  RewriteRule .* ws://localhost:9083%{REQUEST_URI} [P]

ProxyPass "/" "http://localhost:8080/"
ProxyPassReverse "/" "http://localhost:8080/"



If you run into any RTC issues (or are using a configuration different from these), please get in touch. We are here to help however we can!