For secure communications, it is recommended that both the signaling connection and media session be secured for end-to-end communications. The Acme Packet, OpenBranch and Comdasys SBCs (Session Border Controllers) support SIP signaling security via TLS (on both the access and core sides of the SBC) and support media security via transparent pass-thru of SRTP (Secure Real-time Transport Protocol) packets as well as mediation with RTP.
The following figure illustrates generation and distribution of CA (Certification Authority) files to network elements including SBC:
The Acme Packet SBC will also provide full support for the MIKEY (Multimedia Internet Keying) #0 key exchange procedures and will therefore be able to provide mediation between an endpoint device using SRTP on one side of the SBC with an EP (Endpoint) on the other side of the SBC using RTP (Real-time Transport Protocol).
For media sessions the SBC is able to support MIKEY#0 crypto session negotiation in the following combinations with SRTP - RTP session mediation supported as required:
SRTP - SRTP
The media stream is secure when the MIKEY#0 crypto session negotiation is successful for the core and access network. For calls established between users on the SBC access, end-to-end secure media is possible only if the session established from the originator and the session established to the destination use SRTP.
SRTP - RTP
For SRTP media streams the SBC supports the crypto session negotiation and session mediation when RTP is used on the peer network. Note that the SRTP session may be established from either the access or core network.
As of legacy system, the Acme SBC's are only able to support static media associations, i.e., SRTP-SRTP, or RTP-RTP and is unable to support Lotus Sametime Unified Telephony best effort SRTP negotiation. It is planned to support SRTP-RTP in the future.
For transport signaling, the SBC is able to support several transport signaling combinations for the SBC access and SBC core networks. It is recommended that the transport be secured end-to-end however this is not always possible.
For SIP devices and gateways on the SBC access network, Server Authentication TLS (TLS) is recommended, however TCP and UDP are available.
If SBCs are deployed in a cascaded configuration, for the central SBC access side, Mutual Authentication TLS (mTLS) is recommended. On the SBC core network mTLS is recommended, however TCP and UDP are available.
For an Branch (Proxy), mTLS is recommended to be used on the central SBC access, however TCP and UDP are available.
Secure Call User Indications
To ensure end users are provided an accurate indication regarding call security, a proprietary end-to-end call security indication is available. The indication is transported via SIP within the Lotus Sametime Unified Telephony X-Lotus-Call-Type header field. The user will be provided a secure communications indication only if both the calling and called SIP devices support the extension and a secure communications connection is established end-to-end. The call must utilize TLS signaling and SRTP media end-to-end. This can only be achieved where both the SBC access and core are secured using TLS (or mTLS) and SRTP media security is used, i.e., all sessions and signaling traversing the SBC for the call must be secure.
The following call is secure: User A calls User B:
A (TLS+SRTP) -> SBC -> Lotus Sametime Unified Telephony (mTLS+SRTP) -> SBC -> B (TLS+SRTP)
The following call is insecure: User A calls a User in the PSTN accessed via a GW where the GW only supports RTP:
A (TLS+SRTP) -> SBC -> Lotus Sametime Unified Telephony (mTLS+SRTP) -> SBC -> GW (TLS+RTP)
Parent topic: Additional SBC (Session Border Controller) Capabilities