Skip to main content
VoicePing protects public service entry points, administrative connections and data storage separately. Alongside encryption, controls determine who may connect and how potential problems are investigated. Updated October 21, 2026. These diagrams and detection examples describe selected responsibilities. They do not disclose every host, destination, detection rule or limit. 日本語版.

​
System architecture

Web, desktop and mobile apps connect to APIs, meeting communications, speech recognition and translation services. Content delivery, processing and storage use infrastructure suited to each role.
Clients connect to content delivery and core services, which use databases, file storage and authorized external integrations

A conceptual view of system responsibilities, not a complete network or deployment diagram.

The Privacy Policy describes the main cloud platforms and storage locations. Confirm the scope of dedicated or on-premises configurations individually.

​
Encryption in transit

Public web and API connections use HTTPS; realtime WebSocket connections use WSS. WebRTC audio/video transport is protected using mechanisms such as DTLS-SRTP. Different paths use different protocols, so a single TLS version does not describe every connection.
Encrypted app and media connections lead to authorized server processing; transport encryption is distinct from end-to-end encryption

Protecting transport and processing data on a server are distinct responsibilities.

Authorized servers process content for cloud transcription and translation. This differs from end-to-end encryption that prevents the server from reading content. Internal transport and encryption at rest must be checked for the relevant configuration.

​
Public exposure and administrative access

For services behind load balancers, source restrictions help prevent direct connections to backend servers from bypassing controls. Cloud rules, such as AWS security groups, are managed together with host settings. Administrative SSH access uses public-key authentication, and registered keys are inventoried. Key migration and revocation checks verify both acceptance of approved keys and rejection of unnecessary ones. Unreachable hosts or settings that cannot be inspected with the available permissions are recorded separately from verified coverage.
Public service access passes through approved entry points, while administrative access uses approved keys and sources; unauthorized connections are rejected

Public user traffic and operator access follow separately restricted paths.

TURN relays, used when a direct media connection is difficult, also have authentication, expiry and connection limits. Permission to join a meeting and permission to use the relay are checked separately.

​
Detection and request limits by layer

Signals from several layers can lead to investigation or blocking. These are representative examples, not a complete list of rules or decision thresholds.
Review signals from entry points, applications and endpoints, then distinguish request limiting from operator investigation

Rate limiting, permission-based rejection and blocking attack sources serve different purposes.

Rate limiting restricts requests accepted over a period of time. Limits can depend on the IP address, signed-in user or feature. Sensitive operations such as sign-in and recovery have specific controls. Shared organizational networks may place several legitimate users behind one IP address, so their impact must be considered. A usage-limit rejection or ordinary access failure does not by itself prove malicious intent. Blocking and unblocking consider attack indicators, shared IP addresses and previous manual exceptions. Defenses against attacks that saturate network capacity are assessed separately from application request limits. Cloud-monitoring approaches include Amazon GuardDuty threat detection in AWS environments and CloudWatch or custom operational alerts. The scope and configuration used by each service are confirmed during the relevant review.

​
Backup, business continuity and recovery

A backup must support restoration of the required data, not merely exist. Depending on the data and contract, reviews cover scope, frequency, location, retention and recovery procedures.
One flow verifies restoration from backups; a separate flow manages application and configuration changes and rollback

Data restoration and rollback of application/configuration changes are separate procedures.

Earlier descriptions of backup frequency, multiregion storage or recovery times are checked against the current configuration and contract. A working certificate-validation URL is also distinguished from a successfully completed certificate renewal.
If you have any questions, please contact us via this form.

Official Links

Official Website

Visit our official website

X (Twitter)

Follow us on X

Facebook

Like us on Facebook

LinkedIn

Connect on LinkedIn