Lynes Trust Centre

Our cloud infrastructure leverages scalability, multi-level redundancy, and failover options across Amazon Web Services in the Stockholm region of Sweden to reduce latency, maintain reliability, and scalability. AWS data centers are designed and optimized to handle business-critical applications and have multiple levels of built-in redundancy.

Lynes Infrastructure is constructed in such a way that in a disaster situation, the entire service can be set up from scratch in new data centers within a relatively short period.

Structurally, the Lynes application is based on an advanced architecture with hundreds of so-called micro-services. Each type of service is stateless, allowing the service to have multiple copies running in parallel. This provides a stable form of redundancy, meaning that if one copy crashes, there are replacements that can take over while the crashed copy is automatically restarted. Another consequence of this architecture is that the crashed service only affects a small part of the application as a whole, usually a certain function, while everything else operates as usual. The effect of such a single service crash means that only a few end-users experience a barely noticeable temporary disruption in a specific function.

Certain critical service types have built-in autoscaling, meaning the number of copies automatically adjusts based on existing load, with a guaranteed minimum level when the load is at its lowest. This provides security if the load increases unexpectedly for some reason.

There are two independent dedicated fiber connections to each mobile operator, routed through a subcontractor that operates Session Border Controllers at two different physical locations (geographic redundancy). This means we have redundant connections to all mobile operators.

The operator connections use Round-Robin technology, meaning about 50% of the calls automatically go via one connection and the rest on the other connection. Additionally, both connections are always scaled in such a way that if one goes down, the other can take 100% of the calls.

We constantly seek ways to improve product and platform performance by monitoring key performance indicators, such as CPU, system load, memory usage, database load, audio quality level (average MOS), etc.

For further development of the lynes platform, four different service environments are used. In addition to the operational environment used by end-users, there is also two separate so-called Staging environments used for testing and verification of new features and changes. Each developer also has their own development environment.

Before any changes to the application go live on the operational environment, the change is tested and quality assured in the staging environments. Both automatic unit and system tests are used for testing and verification, complemented with manual tests.

Before code progresses from a development environment to the staging environments, it must be reviewed and approved in a review process by at least two different developers. In addition to the purely functional review, the change is evaluated from a scalability and security perspective.

Most service types can be upgraded in full operation and completely unnoticed by the end-user. Regarding upgrades that concern changes in the app’s user interface, version management can be done, enabling a gradual transition to a new version. In this way, the new version can be verified and quality assured by lynes internally before it’s “pushed out” to all end-users.

As for the telephony servers, new instances running the new code can be started at any time, while the old instances are set in so-called drain mode, and first emptied of ongoing calls and then shut down.

The system is continuously monitored with automatic alarms for deviations over specific threshold values regarding, e.g., resource consumption of CPU, memory, bandwidth, disk, etc. The alarms are level-divided to facilitate follow-up and processing.

Lynes has technical staff on standby year-round for potential incidents. Automatic alarms of critical level trigger calls to emergency phones that are outside the PBX. If an alarm is triggered, established routines exist for troubleshooting and escalation.

Internal reviews of routines and processes occur regularly. Also, unannounced “fire drills” are held continuously.

After any form of incident, a thorough analysis of what happened is carried out, and how we can prevent it from happening again. Short-term measures are implemented and operationalized directly, while longer-term measures are planned in order of priority. Any process improvements are also discussed and implemented.

WebRTC is fundamentally used for app calls and conferences, which means the corresponding encryption of audio streams from client to server and from server to client is applied. The signalling uses standard TLS (at least v1.2 and v1.3 where available). For media, SRTP with DTLS is used for key management.

All calls from the app are thus encrypted from client to server (and from server to the receiving client for internal calls), but are decrypted intermediate by the receiving server to facilitate recording, transcoding, etc.

Chat messages are encrypted “in transit” and “at rest”, meaning they are sent encrypted and stored encrypted. This is not to be confused with E2EE (end-to-end encryption) since data after transport is decrypted by the receiving server, and then encrypted again for storage. Using chat for storing passwords, etc., is not recommended. The reason chat messages are decrypted by the server as an intermediary is to enable notifications, searching, integrations with other systems, etc.

Data from connected accounts from external providers such as Office 365 and G Suite are not cached in the app’s database but are fetched in real-time via the external provider’s APIs. Already retrieved data can be cached in the current session on the user’s client for faster viewing. Logging out clears all data stored in cache.

There’s a function to PIN code protect access to answering surveys for extra security. Authentication with Bank-ID for survey responses is also possible. User-based access to survey results in the lynes app can be controlled with the built-in role-based permissions.

JWT is used as a technology for access control. All RPCs send a JWT token for control.

All content data, such as chat messages, audio files, and surveys, are stored in encrypted form.

Backups are taken of the content in all databases daily and stored on AWS in Sweden. Backups are stored for 30 days and then deleted.

Should you have any questions feel free to contact us at:

lynes Technologies Sweden AB

Drottning Kristinas Esplanad 12

170 67 Solna

Email: hello(a)lynes.io