Overview
Reality Defender provides a SIPREC-compliant Session Recording Server, the Reality Defender Session Recording Server (RDSRS), for streaming live call audio from your Session Border Controller (SBC) or SIPREC-enabled telephony platform to the Reality Defender backend for real-time deepfake analysis.
RDSRS is the recommended integration path for enterprise contact centers with existing on-premises or cloud SBC infrastructure, such as Oracle, Ribbon (Sonus), Twilio, and other SIPREC-enabled devices.
This article explains what SIPREC is, how the call flow works, what Reality Defender provides, what you need to provide, and how to establish a connection. It is intended for telephony and network engineers configuring an SBC integration.
What is SIPREC?
SIPREC (RFC 7866) is a standard SIP-based protocol that allows an SBC to fork a copy of live call audio to an external recording server without affecting the underlying call. It defines two roles:
Session Recording Client (SRC): Your SBC. It detects calls of interest and forks a copy of the signaling and media to the recording server.
Session Recording Server (SRS): Reality Defender's RDSRS. It receives the forked SIPREC session and, once analysis is triggered, streams the audio to the Reality Defender detection backend.
Reality Defender analyzes only the external caller's audio channel. Agent-side audio is not required and should not be streamed to RDSRS. Where possible, configure the SBC for selective, single-channel recording, both to preserve bandwidth and to avoid transmitting agent audio unnecessarily.
Prerequisites
Before starting an RDSRS integration, confirm the following:
Platform access: Your organization must have an active Reality Defender account with RealCall enabled. Contact your Reality Defender account team if you need access.
SBC or SIPREC-capable device: A Session Border Controller or equivalent device capable of acting as a SIPREC SRC. Reality Defender maintains integration profiles for Oracle SBC, Ribbon (Sonus) SBC, and Twilio. Other SIPREC-enabled vendors or plain SIP forks can also be supported through service configuration.
A sample SIP INVITE: A representative SIPREC INVITE from your SBC, including the XML metadata body, is required before onboarding. Each SBC vendor implements SIPREC slightly differently, and Reality Defender uses this sample to configure a matching integration profile for your account.
A session identifier plan: The field in the SIPREC signaling that serves as the unique Session ID for each call. See Session identification below.
A connectivity decision: Public internet (SIP/TLS with SRTP), a site-to-site IPSec VPN, or a private cloud peering link (for example, AWS Transit Gateway) for on-premises or high-security deployments. See Connectivity options below.
A network or firewall contact: Someone on your side who can open the outbound and inbound rules described in Network and firewall requirements below.
How the call flow works
Once connected, a typical RDSRS session follows the standard SIPREC session lifecycle.
Step 1: The SBC sends the SIPREC INVITE
When a call of interest begins, your SBC (the SRC) sends a SIP INVITE to RDSRS. The INVITE includes two attachments: a Session Description Protocol (SDP) body describing the media for both call legs, and an XML metadata body (per RFC 7865) describing the participants and how they map to the SDP.
Step 2: RDSRS acknowledges the session
RDSRS responds with a 200 OK and its own SDP. In most configurations, this initial response marks the media as inactive: RDSRS has accepted the session but is not yet recording.
Note: For immediate-start configurations, the 200 OK includes active media. This is only used in integrations that do not support SIP re-INVITE.
Step 3: RDSRS begins recording
By default, Reality Defender starts analyzing the call automatically as soon as the SIPREC session is established.
Alternatively, an integration can be configured so that you trigger analysis with a recording.start call to the Session API for the corresponding Session ID. In either case, once analysis is triggered, RDSRS sends a re-INVITE to the SBC with the media marked active, and audio begins to flow only at that point. For plain SIP integrations, no re-INVITE is sent.
Note: In this context, "recording" means streaming the call's media to Reality Defender for analysis. Depending on configuration, the media is either retained or discarded immediately after analysis completes.
Step 4: Media streams to RDSRS
Audio streams from the SBC to RDSRS as RTP, encrypted as SRTP when SIP/TLS transport is used (see TLS and certificate handling below). Reality Defender processes the caller-side audio in short, overlapping segments and returns results progressively as the call proceeds.
Step 5: The call ends
When the call terminates, the SBC sends a BYE to close the SIPREC session.
If recording should stop before the underlying call ends (for example, following a recording.stop call to the Session API), RDSRS instead sends a re-INVITE with media marked inactive and waits for the final BYE from the SBC. For integrations that do not support SIP re-INVITE, the media is discarded until the BYE is received.
Connectivity options
Reality Defender supports three connectivity paths for streaming SIPREC traffic. Choose one based on your network and security requirements.
Option | Description | Typical requirements |
SIP/TLS + SRTP over the public internet | Signaling is encrypted with TLS and media with SRTP as it traverses the public internet to Reality Defender's SIP listener. | Bi-directional firewall access to Reality Defender's SIP endpoint, a trusted TLS certificate chain, and an SRTP cipher suite negotiated during SDP offer/answer. Mutual TLS is available on request. |
IPSec VPN | A site-to-site IPSec tunnel carries SIP and RTP traffic privately between your network and Reality Defender's AWS environment. | A VPN gateway on your network with a public IP, agreed IKE/IPSec parameters, a shared key or certificate, and defined traffic selectors and subnets. |
Private cloud peering (for example, AWS Direct Connect/Transit Gateway) | A dedicated, private network path links your environment directly to Reality Defender's cloud environment, bypassing the public internet. Recommended for large enterprise or regulated deployments. | A provisioned cross-connect, peering attachment, or partner circuit, and routing/BGP coordination between your network team and Reality Defender. |
For private peering and dedicated deployments, Reality Defender provisions a dedicated SIP endpoint and IP range specific to your account, rather than the shared multi-tenant endpoint described below. Contact your Reality Defender account team to scope this.
RDSRS SIP endpoints
For the standard multi-tenant SaaS deployment, Reality Defender's SIPREC listener is available at the following addresses. All connections use SIP over TLS on port 5061.
Environment | SIP URI | Purpose |
Staging |
| Pre-production validation |
Production |
| Live call traffic |
Note: These hostnames resolve to a set of addresses that may change over time. Your Reality Defender account team provides the current resolved IP addresses and, for private-peering deployments, a dedicated hostname and IP range for firewall allowlisting. See Network and firewall requirements below.
TLS and certificate handling
RDSRS requires SIP/TLS for signaling. SRTP is used for media encryption once negotiated.
Server certificate: RDSRS presents a publicly trusted TLS certificate for its SIP endpoint, issued by a public CA and renewed automatically. The SBC or firewall only needs to trust the standard public CA roots.
TLS version: TLS 1.2 or higher.
Cipher suite: The TLS cipher suite is negotiated during the TLS handshake, and the SRTP crypto suite is negotiated during SDP offer/answer. Reality Defender can align to the cipher list supported by your SBC.
Mutual TLS (mTLS): Available on request for organizations with additional security requirements. If you require mTLS, share your client certificate and CA chain with your Reality Defender account team during onboarding.
Audio codec: Reality Defender expects G.711 µ-law (or A-law outside the United States), the standard telephony codec. Contact your Reality Defender account team to discuss other codecs.
Network and firewall requirements
The following traffic must be permitted between your SBC and Reality Defender, in both directions where noted:
Traffic | Port(s) | Protocol | Direction |
SIP signaling | 5061 | TCP (TLS) | Bi-directional between your SBC and RDSRS when re-INVITE is used, since RDSRS may need to open a new connection to the SBC to send it. Outbound-only from the SBC to RDSRS is sufficient when re-INVITE is not supported. |
Media (RTP/SRTP) | 10,000–60,000 (default range opened at Reality Defender; contact your account team if your environment requires a different range) | UDP | Outbound only, from your SBC to the RDSRS media proxy |
The following traffic must be permitted between your systems and Reality Defender for results delivery. You can use either one or both.
Traffic | Port | Protocol | Direction |
Session API | 443 | HTTPS | Outbound, from your systems to the Reality Defender API |
Webhooks | 443 | HTTPS | Inbound, from Reality Defender's webhook service to your endpoint |
Your Reality Defender account team provides the specific IP addresses (or CIDR range, for private-peered deployments) to allowlist for each item above. The SIP proxy and media proxy addresses differ, and RDSRS may originate re-INVITEs from an address other than the one that received the original INVITE.
SBC vendor support and integration profiles
Each SBC vendor implements SIPREC somewhat differently: header naming, XML metadata structure, and re-INVITE behavior all vary. Reality Defender maintains tested integration profiles for:
Oracle SBC
Ribbon (Sonus) SBC
Twilio SIPREC
Other SIPREC-enabled SBCs, and in specific cases plain SIP (non-SIPREC) sources, can typically also be supported. To configure a new integration profile, Reality Defender requires a sample SIP INVITE from your SBC, including the XML metadata body if available, during onboarding.
Important: Calls that do not match a configured profile are rejected outright, so this step must be completed before go-live.
Session identification
Reality Defender uses a Session ID to uniquely identify each call and its analysis result. For SIPREC integrations, the Session ID can be any value your SBC includes in the SIP headers or XML metadata of the INVITE. This is commonly a call or interaction ID that your telephony or CTI system already generates and can reference later.
By default, RDSRS uses the SIP Call-ID if no other value is specified. Most production integrations use a custom identifier instead, since the SIP Call-ID is not guaranteed to persist through call transfers or conferencing. Confirm with your Reality Defender account team which header or metadata field should serve as the Session ID for your integration.
You can then use the Session ID to:
Start or stop recording through the Session API (
recording.start/recording.stop)Retrieve the analysis result for a call
Look up the call in the Reality Defender dashboard
Getting started
Confirm platform access with your Reality Defender account team and identify the SBC vendor and deployment model.
Choose a connectivity path: public internet, IPSec VPN, or private peering.
Determine which SIP header or metadata field carries the Session ID.
Share a sample SIP INVITE from the SBC, including the XML metadata body, with your Reality Defender account team so an integration profile can be configured.
Open the required firewall rules (see Network and firewall requirements) using the addresses provided by your Reality Defender account team.
Configure the SBC to fork the external caller's audio to the RDSRS endpoint, then validate the integration end to end with test calls.
Confirm that results can be retrieved through the Session API using the chosen Session ID, or received through webhooks if you’ve configured them.
Frequently asked questions
Does Reality Defender record or store agent-side audio?
No. Reality Defender analyzes only the external caller's audio channel. Where possible, configure the SBC for selective recording of the caller leg.
What happens if an SBC's SIPREC dialect is not recognized?
Calls that do not match a configured integration profile are rejected. This is why a sample INVITE must be shared with Reality Defender during onboarding, before go-live.
Is mutual TLS required?
No. Standard one-way TLS, in which the SBC verifies Reality Defender's certificate, is sufficient for most deployments. Mutual TLS is available for organizations with additional security requirements.
Can a private network path be used instead of the public internet?
Yes. IPSec VPN and private cloud peering (such as AWS Direct Connect/Transit Gateway) are both supported and are the recommended path for high-volume or regulated deployments.
Who should I contact for assistance?
Your Reality Defender account team or Customer Success contact can engage a solutions engineer for SIPREC-specific configuration questions.