Edge Features

Proxy Web Features

The Web proxy is configured to:

proxify only the needed route towards the XiVO CC
rate-limit the call to the application
verify that calls to /xuc/api/2.0/cti endpoint (CTI WS) contains a token in the right format in the argument
verify that calls to /wssip and /wssip-MDSNAME endpoint (SIP WS) contains a token in the argument

Certificates and OCSP

By default OCSP is enabled. For OCSP to work the Intermediate Certificate must be correctly installed. Normally this should be ok if you did install the fullchain certificate as specified in the SSL Certificates config section.

If it is not the case one could deactivate OCSP for the web proxy by adding the following in the env file:

OCSP_ENABLE=off

Rate limiting

Simplified explanation on how the nginx rate limit module works :

Rate limit does not apply to Private IP Address (RFC1918)

Rate limiting is configured in three zones and request limits are applied by client ip :

webapp
- 30 req/s, burst of 20 req
  - /ccagent
  - /ucassistant
  - /switchboard
- 30 req/s, burst of 50 req (env variable), nodelay
  - /assets
  - /config
  - /video/css
  - /video/images
  - /video/lang
  - /video/libs
  - /video/sounds
  - /pwa-worker.js
  - /static/offline.html
apis
- 30 req/s, burst of 10 req
  - /xuc
  - /version
- 30 req/s, burst of 10 req, nodelay
  - /video/external_api.js
auth
- 20 req/m, burst of 12 req, nodelay
  - /wssip
  - /xuc/api/2.0/auth/login
  - /xuc/api/2.0/cti
  - /invitation/video
  - /meetingrooms/token/validate/
dapp
- 20 req/m, burst of 15 req, nodelay
  - /install/win64
  - /updates/win64
  - /updates/debian
video
- 20 req/s, burst of 12 req, nodelay
  - /video/
  - /video/xmpp-websocket
  - /video/colibri-ws/

You can tweak the rate limit burst of the asset part by changing the value of the ASSETS_BURST variable.

Token format validation

The token format is checked with a regex. It checks the token contains 3 segments between 15 and 120 characters separated with dots.

TURN Server Features

TURN Credentials

To be able to use the TURN server you must have valid credentials. Credentials are given by the xucserver to the WebRTC client.

These credentials are generated by the xucserver and validated/verified by the TURN server via a shared secret defined:

in xuc via the TURN_SERVER_SECRET variable
in TURN Server via the static-auth-secret parameter

By default only TURN is activated for both asterisk and WebRTC client. This can be changed via the TURN_SERVER_ENABLE and STUN_SERVER_ENABLE variables to be put in the custome.env of the XiVO CC

...
TURN_SERVER_ENABLE=false
STUN_SERVER_ENABLE=true

TURN Credentials lifetime

These credentials are valid for a default lifetime of 3600s. The WebRTC client renew the credential every TTL/2.

The TTL can be changed via the TURN_SERVER_CREDENTIAL_TTL xuc environment variable. To change the credential TTL to 2hours add the following in the XiVOCC custom.env file:

...
TURN_SERVER_CREDENTIAL_TTL=7200

Optimize ICE (STUN/TURN) negotiation time

There are two places where the ICE mechanism can take some time:

Before emitting the call
When call is answered

1. Before emitting the call

When A wants to call B, A will start - before sending the SIP INVITE, by gathering what is called the “candidate”. This is A’s host IP addresses and also what the STUN/TURN server will give him.

The more host IP addresses A has, the longer the STUN/TURN gathering will take. Not to say that it also depends on the fact that these IP addresses can reach the STUN/TURN server.

On the UC Application side this cannot be tweaked. But the candidate gathering process is limited to 2 seconds.
On asterisk side this can be enhanced by setting a stun and ice blacklist rule. This can be done by adding the following lines in a file in /etc/asterisk/rtp.d/ directory (for example /etc/asterisk/rtp.d/02-ice-optimization.conf):
```
stun_deny = 0.0.0.0/0
stun_permit = 10.32.4.0/24

ice_deny = 0.0.0.0/0
ice_permit = 10.32.4.0/24
```

Where 10.32.4.0/24 is the network to which belongs the interface which can access the STUN/TURN server.

You need to reload rtp: asterisk -rx ‘module reload res_rtp_asterisk.so’

Warning

Please read carefully : asterisk documentation https://github.com/asterisk/asterisk/blob/18/configs/samples/rtp.conf.sample
Beware that a mis-configuration there can prevent your WebRTC user to make any call

2. When call is answered

If A calls B, when B answers, A and B will start to negotiate which RTP candidate they will use to communicate. The longer the candidate list for A and B the greater the number of possibility and connectivity check to do.

On the UC Application side there is not much one can do except to shutdown some network interfaces. But the candidate gathering process is limited to 2 seconds.
On asterisk side this can be enhanced by setting a stun and ice blacklist rule. This can be done by adding the following lines in a file in /etc/asterisk/rtp.d/ directory (for example /etc/asterisk/rtp.d/02-ice-optimization.conf):
```
stun_deny = 0.0.0.0/0
stun_permit = 10.32.4.0/24

ice_deny = 0.0.0.0/0
ice_permit = 10.32.4.0/24
```

Where 10.32.4.0/24 is the network to which belongs the interface which can access the STUN/TURN server.

You need to reload rtp: asterisk -rx 'module reload res_rtp_asterisk.so'

Warning

Please read carefully : asterisk documentation https://github.com/asterisk/asterisk/blob/18/configs/samples/rtp.conf.sample
Beware that a mis-configuration there can prevent your WebRTC user to make any call