************* 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 :ref:`edge_config_sslcert` config section. If it is not the case one could deactivate OCSP for the web proxy by adding the following in the :file:`env` file: .. code-block:: ini OCSP_ENABLE=off .. _OCSP: https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol Rate limiting ------------- Simplified explanation on how the nginx rate limit module works : .. figure:: images/edge_nginx_ratelimiting.png :alt: edge_nginx_ratelimiting 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 : 1. **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 2. **apis** - **30 req/s, burst of 10 req** - /xuc - /version - **30 req/s, burst of 10 req, nodelay** - /video/external_api.js 3. **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/ 4. **dapp** - **20 req/m, burst of 15 req, nodelay** - /install/win64 - /updates/win64 - /updates/debian 5. **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: 1. Before emitting the call 2. 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 :file:`/etc/asterisk/rtp.d/` directory (for example :file:`/etc/asterisk/rtp.d/02-ice-optimization.conf`): .. code-block:: ini 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 :file:`/etc/asterisk/rtp.d/` directory (for example :file:`/etc/asterisk/rtp.d/02-ice-optimization.conf`): .. code-block:: ini 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