The web application is part of the trust model
A secure media protocol does not rescue an application that gives arbitrary users privileged calling credentials. Protect the web origin, session handling and the code delivered to the browser. Restrict endpoint permissions to the user's actual role and separate administration from calling access. Treat third-party scripts on a calling page as part of the exposure review. The browser application can influence capture and signaling, so its integrity matters alongside the PBX's firewall rules.
Limit relay and endpoint authority
Use authenticated TURN service, bounded credentials and monitoring. Keep SIP calling permissions narrow even for successfully authenticated users. Test logout and credential expiry, including whether an existing socket or registration remains usable longer than intended. Review what candidate and diagnostic data is retained. Addresses, account identifiers and call metadata can be sensitive even when audio remains encrypted. A relay-only policy may reduce peer address exposure but has capacity and availability consequences; describe those tradeoffs explicitly.
Verify the actual media endpoint
Identify where DTLS-SRTP terminates and whether the next leg is protected. Recording or mixing at a server changes the trust relationship. Avoid saying end-to-end encrypted when the service decrypts audio at its media server. For an operational review, test a revoked account, expired certificate, denied microphone permission and unavailable relay. Confirm errors are understandable and do not suggest bypassing certificate validation. Preserve the minimum evidence needed to investigate, with a defined retention period and access policy.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.