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
- 30 req/s, burst of 20 req
apis
- 30 req/s, burst of 10 req
- /xuc
- /version
- 30 req/s, burst of 10 req, nodelay
- /video/external_api.js
- 30 req/s, burst of 10 req
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/
- 20 req/m, burst of 12 req, nodelay
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