SIPREC: Difference between revisions

From VoIPmonitor.org
No edit summary
(Rewrite: konsolidace a vylepšení struktury)
Line 1: Line 1:
{{DISPLAYTITLE:VoIPmonitor SIPREC Integration Guide: Compliance-Ready Call Recording for Legal and Business Needs}}
= SIPREC =
VoIPmonitor is a powerful VoIP packet sniffer and call recording tool that now offers robust SIPREC (Session Recording Protocol) support as a Session Recording Server (SRS). This dual capability means calls can be recorded either by capturing network packets directly or by receiving SIPREC streams from SIP infrastructure, providing seamless, standards-compliant call recording. This guide explores SIPREC’s role in call recording compliance across industries (with examples from the US and beyond) and how VoIPmonitor can be leveraged for both technical integration and commercial advantage. We cover meeting regulatory requirements like U.S. CFTC, FINRA, SEC rules, European MiFID II, and public safety standards like NENA i3, as well as best practices for PCI-DSS. By implementing VoIPmonitor as a SIPREC recorder, organizations enhance interoperability, ensure data immutability for legal audits, and open new revenue opportunities with compliance-driven solutions.
SIPREC (Session Recording Protocol, RFC 7866/7865) is an IETF standard for recording SIP-based communications. VoIPmonitor acts as a '''Session Recording Server (SRS)''' that receives call streams from SIPREC-enabled SIP proxies or SBCs.


== What is SIPREC? ==
== How SIPREC Works ==
SIPREC is an open IETF standard (defined in RFC 7866, with an associated metadata model in RFC 7865) for recording SIP-based communication sessions. It allows a SIP proxy or session border controller (SBC) to fork copies of voice/media streams to a dedicated recording server without disrupting the original call flow.


* '''Key Components:'''
<kroki lang="plantuml">
** '''Session Recording Client (SRC):''' The network element (e.g., SIP proxy, IP-PBX, or SBC such as OpenSIPS, Kamailio, Cisco CUBE) that initiates the recording session. The SRC sends call metadata (in an XML format) and media streams (RTP/SRTP) to the recorder (SRS).
@startuml
** '''Session Recording Server (SRS):''' The recorder that receives, stores, and processes the duplicated session (for instance, VoIPmonitor when configured as the SIPREC server).
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}
title SIPREC Recording Flow


* '''Key Benefits:'''
[Caller] --> [SIP Proxy/SBC\n(SRC)] : SIP Call
** '''Compliance-ready recording:''' Helps meet legal call-recording mandates in regulated sectors like finance, public safety, and enterprise. (For example, trading regulations or emergency service standards often require all relevant calls to be logged and retained.)
[SIP Proxy/SBC\n(SRC)] --> [Callee] : SIP Call
** '''Non-intrusive capture:''' The SRS is a passive endpoint for recordings. The recording session runs parallel to the main call via SIP signaling, so it does not interfere with call quality or reliability.
[SIP Proxy/SBC\n(SRC)] -[#2F6CB0]-> [VoIPmonitor\n(SRS)] : SIPREC INVITE\n+ XML metadata
** '''Scalability for complex calls:''' Supports multi-party calls, conference calls, and rich metadata exchange. SIPREC’s metadata (XML) describes participants, call identifiers, timing, etc., enabling accurate reconstruction of complex call scenarios in the recordings.
[SIP Proxy/SBC\n(SRC)] ..> [RTP Proxy] : Original RTP
** '''Interoperability:''' SIPREC is supported by many VoIP platforms (OpenSIPS, Kamailio, FreeSWITCH, etc.) and commercial SBCs (Cisco, Oracle, AudioCodes, Avaya, etc.). This broad support means a VoIPmonitor SRS can integrate with various vendors out-of-the-box, easing deployment in heterogeneous environments.
[RTP Proxy] -[#2F6CB0]-> [VoIPmonitor\n(SRS)] : Mirrored RTP
 
[VoIPmonitor\n(SRS)] --> [Storage] : PCAP + CDR
In a SIPREC workflow, the SRC (e.g., a PBX or proxy) sends a SIP INVITE to the SRS (recorder), embedding call details in the body (XML metadata) and then forwarding the RTP media streams. This standardized method is ideal for use cases where regulations require call recording. It lets service providers or businesses adopt solutions like VoIPmonitor to meet compliance needs without proprietary integrations, ultimately increasing the appeal and deployability of their recording system.
@enduml
 
</kroki>
== SIPREC for Legal Compliance ==
SIPREC has become a key enabler for compliance call recording in regulated industries worldwide. Laws and regulations typically mandate the recording and retention of certain communications, but they don’t always dictate how. By providing a standard way to capture calls and metadata, SIPREC helps organizations meet these requirements in an interoperable manner. VoIPmonitor’s support for SIPREC makes it a valuable tool for companies looking to comply with regulations (and even turn compliance into a selling point for their services).
 
* '''Financial Services (CFTC, FINRA, MiFID II):''' In the U.S., the Commodity Futures Trading Commission (CFTC) requires retention of all oral communications leading to commodity trades (e.g., CFTC Rules 23.202 and 1.35). FINRA’s Taping Rule 3170 mandates that certain broker-dealers systematically record calls. Meanwhile, in the EU, MiFID II and related regulations require investment firms to record and securely store communications (typically for 5+ years) that may result in a transaction. VoIPmonitor’s SIPREC SRS supports immutable storage and audit trails — aligning with SEC Rule 17a-4(f) and CFTC Rule 1.31 (which call for tamper-proof records) — helping financial organizations meet these strict record-keeping requirements.
 
* '''Next-Generation Emergency Services (NG9-1-1, NENA i3):''' The National Emergency Number Association’s i3 standard in the US mandates SIP-based call logging for Next Generation 9-1-1. Specifically, SIPREC is used for delivering 9-1-1 call audio and metadata to logging recorders (the SRS) in Public Safety Answering Points. VoIPmonitor’s SIPREC functionality allows PSAPs to implement redundant, metadata-rich recording of emergency calls as required by NG9-1-1 standards. (Similar initiatives internationally are also adopting IP/SIP-based recording for emergency services.)
 
* '''Enterprise Call Recording & Contact Centers:''' Businesses must navigate various call recording laws and privacy rules. For instance, call consent laws differ by jurisdiction (some regions or U.S. states require one-party consent, others require all-party consent for recording). SIPREC facilitates easy integration with existing phone systems (SBCs or PBXs), whether for always-on recording or on-demand capture triggered by policy. VoIPmonitor’s recorder can enforce data privacy measures — e.g. providing options to announce or beep during recording for consent, and offering pause/resume or data masking to avoid capturing sensitive information (useful for standards like PCI-DSS). This ensures that enterprises can record calls for quality or compliance purposes without violating privacy regulations.
 
* '''Business Case for VoIPmonitor’s SIPREC Feature:''' As regulations drive mandatory call recording in finance, public safety, and other fields, having SIPREC capabilities boosts VoIPmonitor’s marketability. VoIPmonitor as an SRS can easily integrate with SIPREC-enabled platforms (from open-source proxies to commercial SBCs like Cisco CUBE or Avaya Aura), allowing solution providers to offer “compliance-ready” call recording services. Features such as selective vs. always-on recording, multi-tenant support, long-term archiving, and e-discovery interfaces add value for clients. By leveraging these, vendors or IT teams can increase adoption of VoIPmonitor in environments where compliance is a key requirement, both in the US and internationally.
 
== VoIPmonitor as a SIPREC Server ==
VoIPmonitor can function as a fully compliant SIPREC recording server (SRS) while still performing its traditional packet-sniffing capture. When SIPREC mode is enabled, VoIPmonitor listens for recording sessions from one or more Session Recording Clients and handles multiple streams of SIP signaling and RTP media. This flexibility means you can deploy VoIPmonitor in parallel with your existing network capture setup or use it purely as an SRS, depending on your needs.
 
* '''Dual Recording Modes:''' VoIPmonitor supports both native packet capture (sniffing traffic on network interfaces) and SIPREC-based capture (receiving streams via SIP). These modes can run concurrently, so an operator can record some calls via SIPREC while still capturing others via a SPAN port or network tap. This dual capability provides maximum deployment flexibility.
 
* '''Full SIPREC Compliance (RFC 7866 & 7865):''' Implements the standard SIP-based recording protocol, including handling of SDP and recording metadata (per RFC 7865). VoIPmonitor as SRS accepts SIPREC INVITEs, parses the included <code><recording_metadata></code> XML to correlate recorded call legs, and receives the RTP/SRTP streams for each session. It can also operate in secure environments (with TLS/SRTP) if properly configured, ensuring compliance with modern security requirements.
 
* '''Retention and Immutability:''' Offers policy-based retention and write-once storage options to meet record-keeping regulations. For example, recordings can be stored in an immutable format or on write-protected media (such as using S3 Object Lock or other WORM storage) to comply with SEC Rule 17a-4(f) and CFTC Rule 1.31, which require tamper-proof archives. Audit logs and cryptographic hashes of recordings provide a detailed trail to prove data integrity.
 
* '''Selective vs. Always-On Recording:''' Supports both selective recording (e.g. triggered by an API call, user action, or predefined rules to record only specific calls) and always-on recording of all calls. VoIPmonitor’s SIPREC implementation can handle thousands of simultaneous sessions, and its multi-tenant architecture allows segregating recordings by client or department — useful for service providers or large enterprises.


* '''Privacy and Consent Features:''' Provides tools to help comply with privacy laws and obtain consent. For example, VoIPmonitor can log and/or enforce that call recording announcements or beep tones are used, and it allows integration of triggers to stop or skip recording when needed. Administrators can configure it to anonymize or omit certain data from records to align with regulations like GDPR or CCPA.
'''Key components:'''
* '''Session Recording Client (SRC):''' SIP proxy, PBX, or SBC (OpenSIPS, Kamailio, Cisco CUBE, AudioCodes, Oracle, Avaya) that initiates recording by forking media/metadata to the SRS
* '''Session Recording Server (SRS):''' VoIPmonitor receives SIPREC INVITEs with XML metadata and RTP/SRTP streams


* '''PCI-DSS Safe Recording:''' In environments like contact centers handling payments, VoIPmonitor supports PCI-DSS compliance by preventing sensitive cardholder data from being stored. Features include DTMF tone suppression (so credit card numbers entered via phone keypad are not captured in recordings) and the ability to pause/resume or mute segments of the recording via API when agents handle sensitive information, ensuring no prohibited data is recorded.
'''Benefits over packet sniffing:'''
* Receives call metadata (participants, timestamps, call-IDs) automatically via XML
* Works in cloud/multi-tenant environments where port mirroring isn't possible
* Standard protocol supported by most VoIP vendors


* '''Compliance & E-Discovery Support:''' VoIPmonitor’s recordings include detailed metadata (caller/callee IDs, timestamps, call IDs, participant info, etc.), which simplifies search and retrieval for compliance audits or legal discovery. It provides secure export and playback of recordings with chain-of-custody tracking and can enforce legal hold (preventing deletion of specific records). These capabilities ensure organizations can readily produce recordings to regulators or courts, with confidence in their authenticity.
{{Note|1=SIPREC and packet capture can run concurrently - enabling SIPREC doesn't disable native sniffing.}}


== Enabling SIPREC in VoIPmonitor (Configuration) ==
== VoIPmonitor Configuration ==
To activate SIPREC functionality in VoIPmonitor, you will need to adjust its configuration file (typically <code>/etc/voipmonitor.conf</code>). At minimum, set the IP address and port on which the VoIPmonitor service should listen for SIPREC sessions. Below is an example of the relevant configuration parameters:


<pre>
Add to <code>/etc/voipmonitor.conf</code>:
# SIPREC support - enable VoIPmonitor as a SIP recording server (SRS).
# This works in addition to VoIPmonitor's native packet capture; you can use either or both.
# Use SIPREC for standards-based recording (RFC 7866) to meet compliance needs (CFTC, FINRA, SEC 17a-4, NENA i3, PCI-DSS, etc).
# To enable, set at least siprec_bind and siprec_bind_port.
# Also configure your SIP proxy or SBC (e.g., OpenSIPS, Kamailio, Cisco CUBE, Oracle SBC) as the SRC to send recordings to this SRS.


# IP address to bind the SIPREC server to (0.0.0.0 listens on all interfaces)
<syntaxhighlight lang="ini">
# Enable SIPREC server
siprec_bind = 0.0.0.0
siprec_bind = 0.0.0.0
# Port to listen on for SIPREC INVITE sessions (default example here: 5099)
siprec_bind_port = 5099
siprec_bind_port = 5099
</syntaxhighlight>


# Optional parameters for media handling:
{| class="wikitable"
# Lower bound of UDP port range for incoming RTP streams (default: 10000)
! Parameter !! Default !! Description
siprec_rtp_min = 10000
|-
| <code>siprec_bind</code> || (none) || IP address to bind (0.0.0.0 = all interfaces). '''Required to enable SIPREC.'''
|-
| <code>siprec_bind_port</code> || (none) || SIP port for SIPREC INVITEs (e.g., 5099). '''Required.'''
|-
| <code>siprec_rtp_min</code> || 10000 || Lower bound of UDP port range for RTP
|-
| <code>siprec_rtp_max</code> || 20000 || Upper bound of UDP port range for RTP
|-
| <code>siprec_rtp_stream_timeout_s</code> || 300 || Timeout (seconds) for RTP inactivity before ending session
|-
| <code>siprec_rtp_streams_max_threads</code> || 2 || Max threads for RTP processing
|-
| <code>siprec_rtp_streams_max_per_thread</code> || 100 || Max RTP streams per thread before spawning new thread
|}


# Upper bound of UDP port range for incoming RTP streams (default: 20000)
After configuration:
siprec_rtp_max = 20000
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
</syntaxhighlight>


# Timeout (seconds) for inactivity on all RTP streams (call ends if media stops; default: 300)
== SIP Proxy Configuration ==
siprec_rtp_stream_timeout_s = 300


# Maximum number of threads for RTP packet processing (default: 2)
Configure your SRC to send SIPREC sessions to <code>sip:VOIPMONITOR_IP:5099</code>.
siprec_rtp_streams_max_threads = 2


# Maximum RTP streams per thread before spinning up a new thread (default: 100)
=== OpenSIPS ===
siprec_rtp_streams_max_per_thread = 100
<syntaxhighlight lang="c">
</pre>
 
After updating these settings, restart the VoIPmonitor service (for example, <code>systemctl restart voipmonitor</code> on Linux). Once running, VoIPmonitor will listen on the configured <code>siprec_bind:siprec_bind_port</code> (in our example, all interfaces on port 5099) for incoming SIPREC calls. (Note: Enabling SIPREC does not disable VoIPmonitor’s regular interface-based capture; it simply adds an additional way to ingest calls.) With this configuration in place, VoIPmonitor is ready to accept recordings from your SIPREC-enabled endpoints – a setup designed to meet stringent standards such as FINRA Rule 3170 or CFTC Rule 1.35 for call retention.
 
== Setting Up SIP Proxies/SBCs for SIPREC ==
In a SIPREC deployment, the Session Recording Client is typically your call-control element (the PBX, proxy, or SBC) that forks media to the recorder. You need to configure that device to send recording sessions to VoIPmonitor’s SRS. This usually involves specifying the recorder’s SIP URI (e.g. <code>sip:VOIPMONITOR_IP:5099</code>) in the SRC’s configuration and enabling SIPREC on the calls to be recorded.
 
Below are examples for configuring two popular open-source SIP proxies, OpenSIPS and Kamailio, to act as SRCs sending calls to VoIPmonitor. (For commercial SBCs like Cisco CUBE, AudioCodes, Oracle, Avaya etc., the configuration will be vendor-specific, but generally you set the “Recording Server” address to <code>sip:your-voipmonitor-ip:5099</code> and enable SIPREC on the desired call policies.)
 
=== OpenSIPS Configuration ===
<pre>
loadmodule "siprec.so"
loadmodule "siprec.so"


# Set VoIPmonitor as the recording server (SRS)
modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099")
modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099")  # VoIPmonitor SRS (IP:port)
modparam("siprec", "media_server_uri", "rtpengine")
modparam("siprec", "media_server_uri", "rtpengine") # Media proxy for RTP duplication


# Routing logic to start recording on certain calls
route[record] {
route[record] {
     siprec_start("both");
     siprec_start("both");
}
}
</pre>
</syntaxhighlight>


=== Kamailio Configuration ===
=== Kamailio ===
<pre>
<syntaxhighlight lang="c">
loadmodule "siprec.so"
loadmodule "siprec.so"


modparam("siprec", "recorder_id", "kamailio-rec") # Optional identifier for the recorder
modparam("siprec", "recorder_id", "kamailio-rec")
modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099") # VoIPmonitor SRS destination
modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099")


request_route {
request_route {
Line 111: Line 95:
     }
     }
}
}
</pre>
</syntaxhighlight>
 
=== Commercial SBCs ===
For Cisco CUBE, AudioCodes, Oracle, Avaya: set the "Recording Server" address to <code>sip:VOIPMONITOR_IP:5099</code> and enable SIPREC on desired call policies. Refer to vendor documentation.
 
== Testing ==


In these examples, the SIP proxy uses a media relay (like RTPengine) to duplicate the RTP streams to the VoIPmonitor server. This ensures the call audio is forwarded to the SRS without altering the original call. Once such configuration is in place, the SRC will establish a second call leg toward VoIPmonitor whenever a call needs to be recorded, sending both SIP signaling (with recording metadata) and media. This fulfills the requirements for compliance recording (for instance, providing a record of 9-1-1 calls per NENA i3, or capturing trader conversations for CFTC/FINRA audits).
# Ensure RTP proxy (RTPengine/RTPproxy) is running
# Start SIP proxy with SIPREC enabled
# Start VoIPmonitor and verify SIPREC is listening (check logs)
# Place a test call through the proxy
# Verify call appears in VoIPmonitor with metadata


== Testing SIPREC Integration ==
{{Tip|1=Use <code>sngrep</code> to watch SIPREC INVITE signaling between SRC and VoIPmonitor.}}
Once the configuration is in place, perform a test to ensure VoIPmonitor and your SIPREC setup are working correctly:


Start or ensure the RTP media proxy (e.g., RTPengine or RTPproxy) is running, since it will handle mirroring media to the recorder.
== Firewall Requirements ==


Launch your SIP proxy/SBC with the SIPREC (SRC) configuration enabled (as shown above for OpenSIPS/Kamailio, or per your SBC’s instructions).
Open these ports on the VoIPmonitor server:
* '''TCP/UDP 5099''' (or your configured SIPREC port) - SIP signaling
* '''UDP 10000-20000''' (or your configured range) - RTP media streams


Start VoIPmonitor (the SRS) and confirm it is listening on the SIPREC IP/port (check VoIPmonitor’s logs for a message indicating the SIPREC server is active).
== Compliance Use Cases ==


Place a test call through the system that should be recorded. For example, use two softphones (or SIP endpoints) to make a call through your proxy/PBX that triggers SIPREC. Verify that the call is captured by VoIPmonitor – you should see the SIPREC INVITE with metadata in VoIPmonitor’s console or logs, and afterwards find the call’s details and audio in VoIPmonitor’s storage. (Tip: Tools like <code>sngrep</code> or Wireshark are helpful to watch the SIP signaling. Running <code>sngrep</code> on the proxy or VoIPmonitor server will show the SIPREC INVITE being sent and the recording session being established.)
SIPREC helps meet call recording requirements:


== Architecture Diagram (PlantUML) ==
{| class="wikitable"
<kroki lang="plantuml">
! Industry !! Regulations !! Requirement
@startuml
|-
skinparam shadowing false
| Financial Services || CFTC Rules 23.202/1.35, FINRA 3170, SEC 17a-4(f), MiFID II || Record and retain trader communications with tamper-proof storage
skinparam defaultFontName Arial
|-
skinparam rectangle {
| Emergency Services || NENA i3 (NG9-1-1) || SIP-based logging of 9-1-1 calls with metadata
BorderColor #4A90E2
|-
BackgroundColor #FFFFFF
| Contact Centers || PCI-DSS || Avoid recording cardholder data (pause/resume, DTMF masking)
stereotypeFontColor #333333
|}
}
skinparam packageBorderColor #B0BEC5
skinparam packageBackgroundColor #F7F9FC
title SIPREC Architecture with VoIPmonitor for Compliance
package "SIP Proxy/SBC (SRC)" {
[SIP Proxy / SBC] as SRC
[RTP Proxy] as RTP
}
package "Recording Server (SRS)" {
[VoIPmonitor] as VM
database "Compliant Storage\n(PCAP & CDR Archive)" as Storage
}
[Caller] --> SRC : SIP Call (CS)
SRC --> [Callee] : SIP Call (CS)
SRC -[#2F6CB0]-> VM : SIPREC Invite + Metadata
SRC <--> RTP : RTP Media (Call)
VM <--> RTP : Mirrored RTP Streams
VM --> Storage : Save PCAP + CDR (Immutable)
@enduml
</kroki>


== FAQ & Common Pitfalls ==
VoIPmonitor supports:
* Immutable storage with audit trails (for SEC 17a-4, CFTC 1.31)
* Selective or always-on recording
* DTMF suppression and pause/resume API for PCI-DSS
* Detailed metadata for e-discovery and legal hold


* '''How does VoIPmonitor help with FINRA/CFTC compliance?''' VoIPmonitor’s SIPREC recordings can be stored with immutability and detailed audit logs, which helps firms meet requirements like SEC Rule 17a-4(f) and CFTC Rule 1.31. By capturing all trader calls (per FINRA 3170 or CFTC 23.202 rules) and storing them in tamper-evident form, it ensures regulators can later review communications if needed.
== FAQ ==


* '''Can VoIPmonitor’s SIPREC recording meet PCI-DSS requirements?''' Yes. VoIPmonitor includes options to avoid recording sensitive authentication data. For example, you can use the API or triggers to pause and resume recording during credit card number entry, and VoIPmonitor can mask DTMF tones (or detect patterns that resemble card numbers) so that protected data is not stored in call audio or logs.
'''Q: Can I use SIPREC and packet capture simultaneously?'''
Yes. Enabling SIPREC doesn't disable native capture. Both can run concurrently.


* '''What if my PBX/SBC doesn’t support SIPREC?''' SIPREC is optional – if your telephony platform cannot act as an SRC, you can still use VoIPmonitor in its native capture mode. By mirroring traffic (e.g., using a switch’s port mirroring or network tap), you can capture and record calls without SIPREC. In other words, VoIPmonitor can always record VoIP calls via packet sniffing; SIPREC is just an additional method when available.
'''Q: What if my PBX doesn't support SIPREC?'''
Use VoIPmonitor's native packet capture mode with port mirroring or network tap.


* '''Why use SIPREC instead of port mirroring for call recording?''' Deploying SIPREC can be simpler and more informative in many scenarios. It doesn’t require network-level mirroring configuration, which is useful in cloud or multi-tenant environments where packet sniffing might be difficult. Additionally, SIPREC provides call metadata (identifiers, participants, timestamps) automatically, whereas raw packet capture might require additional processing to extract that information. In compliance terms, using the standard protocol ensures compatibility with various systems (e.g., a Cisco or Avaya SBC can directly push recordings to VoIPmonitor) and captures all required details of the communication.
'''Q: Why choose SIPREC over port mirroring?'''
* Easier in cloud/multi-tenant environments
* Automatic call metadata via XML
* Vendor-agnostic standard protocol


* '''Can VoIPmonitor capture via SIPREC and network sniffing at the same time?''' Yes. Enabling SIPREC in VoIPmonitor does not disable its normal packet-capture functionality. You can, for example, have VoIPmonitor sniffing on a telephony trunk or mirror port for some calls while also receiving SIPREC recordings from a cloud PBX – all concurrently. The system will manage both sources and store calls uniformly in its database.
'''Q: How does this help with FINRA/CFTC compliance?'''
Recordings are stored with immutability and audit logs per SEC 17a-4(f) and CFTC 1.31 requirements.


* '''Do I need to open firewall ports for SIPREC?''' Make sure that the SIP port you configured for SIPREC (5099 in our example) is reachable by the SIPREC clients, as well as the UDP ports for RTP (e.g., the 10000–20000 range by default). If VoIPmonitor is behind a firewall or in the cloud, you'll need to allow inbound SIP on the SIPREC port and inbound UDP on the RTP range. Without these ports open, the SRC won’t be able to send the recording sessions to the SRS.
== See Also ==
* [[Sniffer_configuration]] - Native packet capture configuration
* [[GUI_CDR_viewer]] - Viewing recorded calls
* [[Storing_audio]] - Audio storage options


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' This guide covers how to integrate VoIPmonitor as a SIPREC server (SRS) for compliance-focused call recording. It explains SIPREC basics and its importance in meeting legal requirements globally (with examples like U.S. CFTC 23.202/1.35, FINRA 3170, SEC 17a-4, and EU MiFID II), as well as standards like NENA i3 for NG9-1-1 and PCI-DSS guidelines. We outline the business case for VoIPmonitor’s SIPREC feature (in finance, emergency services, enterprises), detailed steps to configure VoIPmonitor (voipmonitor.conf) and SIP proxies (OpenSIPS, Kamailio, Cisco, etc.) for SIPREC, testing methods, an architecture diagram, and FAQs. VoIPmonitor supports both native packet capture and SIPREC, enabling flexible, immutable, and scalable recording solutions that meet strict regulatory demands.
'''Summary:''' SIPREC (RFC 7866/7865) is an IETF standard for SIP call recording. VoIPmonitor acts as a Session Recording Server (SRS) receiving streams from SIPREC-enabled proxies/SBCs (the SRC). Configuration requires <code>siprec_bind</code> and <code>siprec_bind_port</code> in voipmonitor.conf. SIPREC can run alongside native packet capture. Benefits include automatic metadata, cloud compatibility, and vendor interoperability. Supports compliance requirements for financial services (CFTC, FINRA, SEC, MiFID II), emergency services (NENA i3), and PCI-DSS.


'''Keywords:''' SIPREC compliance, VoIPmonitor SIP recording, VoIPmonitor SRS, CFTC call recording, FINRA Taping Rule 3170, SEC 17a-4 retention, MiFID II call recording, NENA i3 NG9-1-1 logging, PCI-DSS voice recording, legal call recording solution, SIPREC business case, RFC 7866 recorder, VoIPmonitor packet capture vs SIPREC, compliance call recording tool
'''Keywords:''' SIPREC, Session Recording Protocol, RFC 7866, RFC 7865, SRS, SRC, call recording, VoIPmonitor SIPREC, siprec_bind, OpenSIPS siprec, Kamailio siprec, compliance recording, CFTC, FINRA, MiFID II, NENA i3, PCI-DSS


'''Key Questions:'''
'''Key Questions:'''
* How does VoIPmonitor’s SIPREC support help financial firms comply with regulations (CFTC, FINRA, MiFID II)?
* How do I enable SIPREC in VoIPmonitor?
* What is the advantage of using SIPREC in VoIPmonitor compared to traditional packet sniffing for call recording?
* What is the difference between SIPREC and packet capture?
* How do I configure VoIPmonitor as a SIPREC server to meet standards like SEC 17a-4 or NENA i3?
* How to configure OpenSIPS or Kamailio for SIPREC with VoIPmonitor?
* Can VoIPmonitor’s SIPREC feature ensure PCI-DSS compliance for call recordings (e.g., not storing credit card data)?
* What ports need to be open for SIPREC?
* What are the steps to integrate a SIP proxy (OpenSIPS/Kamailio) or an SBC (Cisco, etc.) with VoIPmonitor using SIPREC?
* Can VoIPmonitor use SIPREC and packet sniffing at the same time?
* How does SIPREC help with CFTC/FINRA/MiFID II compliance?

Revision as of 11:08, 19 January 2026

SIPREC

SIPREC (Session Recording Protocol, RFC 7866/7865) is an IETF standard for recording SIP-based communications. VoIPmonitor acts as a Session Recording Server (SRS) that receives call streams from SIPREC-enabled SIP proxies or SBCs.

How SIPREC Works

Key components:

  • Session Recording Client (SRC): SIP proxy, PBX, or SBC (OpenSIPS, Kamailio, Cisco CUBE, AudioCodes, Oracle, Avaya) that initiates recording by forking media/metadata to the SRS
  • Session Recording Server (SRS): VoIPmonitor receives SIPREC INVITEs with XML metadata and RTP/SRTP streams

Benefits over packet sniffing:

  • Receives call metadata (participants, timestamps, call-IDs) automatically via XML
  • Works in cloud/multi-tenant environments where port mirroring isn't possible
  • Standard protocol supported by most VoIP vendors

ℹ️ Note: SIPREC and packet capture can run concurrently - enabling SIPREC doesn't disable native sniffing.

VoIPmonitor Configuration

Add to /etc/voipmonitor.conf: 

# Enable SIPREC server
siprec_bind = 0.0.0.0
siprec_bind_port = 5099
Parameter Default Description
siprec_bind (none) IP address to bind (0.0.0.0 = all interfaces). Required to enable SIPREC.
siprec_bind_port (none) SIP port for SIPREC INVITEs (e.g., 5099). Required.
siprec_rtp_min 10000 Lower bound of UDP port range for RTP
siprec_rtp_max 20000 Upper bound of UDP port range for RTP
siprec_rtp_stream_timeout_s 300 Timeout (seconds) for RTP inactivity before ending session
siprec_rtp_streams_max_threads 2 Max threads for RTP processing
siprec_rtp_streams_max_per_thread 100 Max RTP streams per thread before spawning new thread

After configuration: 

systemctl restart voipmonitor

SIP Proxy Configuration

Configure your SRC to send SIPREC sessions to sip:VOIPMONITOR_IP:5099.

OpenSIPS

loadmodule "siprec.so"

modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099")
modparam("siprec", "media_server_uri", "rtpengine")

route[record] {
    siprec_start("both");
}

Kamailio

loadmodule "siprec.so"

modparam("siprec", "recorder_id", "kamailio-rec")
modparam("siprec", "recorder_uri", "sip:192.168.1.12:5099")

request_route {
    if (is_method("INVITE")) {
        siprec_start("both");
    }
}

Commercial SBCs

For Cisco CUBE, AudioCodes, Oracle, Avaya: set the "Recording Server" address to sip:VOIPMONITOR_IP:5099 and enable SIPREC on desired call policies. Refer to vendor documentation.

Testing

  1. Ensure RTP proxy (RTPengine/RTPproxy) is running
  2. Start SIP proxy with SIPREC enabled
  3. Start VoIPmonitor and verify SIPREC is listening (check logs)
  4. Place a test call through the proxy
  5. Verify call appears in VoIPmonitor with metadata

💡 Tip: Use sngrep to watch SIPREC INVITE signaling between SRC and VoIPmonitor.

Firewall Requirements

Open these ports on the VoIPmonitor server:

  • TCP/UDP 5099 (or your configured SIPREC port) - SIP signaling
  • UDP 10000-20000 (or your configured range) - RTP media streams

Compliance Use Cases

SIPREC helps meet call recording requirements:

Industry Regulations Requirement
Financial Services CFTC Rules 23.202/1.35, FINRA 3170, SEC 17a-4(f), MiFID II Record and retain trader communications with tamper-proof storage
Emergency Services NENA i3 (NG9-1-1) SIP-based logging of 9-1-1 calls with metadata
Contact Centers PCI-DSS Avoid recording cardholder data (pause/resume, DTMF masking)

VoIPmonitor supports:

  • Immutable storage with audit trails (for SEC 17a-4, CFTC 1.31)
  • Selective or always-on recording
  • DTMF suppression and pause/resume API for PCI-DSS
  • Detailed metadata for e-discovery and legal hold

FAQ

Q: Can I use SIPREC and packet capture simultaneously? Yes. Enabling SIPREC doesn't disable native capture. Both can run concurrently.

Q: What if my PBX doesn't support SIPREC? Use VoIPmonitor's native packet capture mode with port mirroring or network tap.

Q: Why choose SIPREC over port mirroring?

  • Easier in cloud/multi-tenant environments
  • Automatic call metadata via XML
  • Vendor-agnostic standard protocol

Q: How does this help with FINRA/CFTC compliance? Recordings are stored with immutability and audit logs per SEC 17a-4(f) and CFTC 1.31 requirements.

See Also

AI Summary for RAG

Summary: SIPREC (RFC 7866/7865) is an IETF standard for SIP call recording. VoIPmonitor acts as a Session Recording Server (SRS) receiving streams from SIPREC-enabled proxies/SBCs (the SRC). Configuration requires siprec_bind and siprec_bind_port in voipmonitor.conf. SIPREC can run alongside native packet capture. Benefits include automatic metadata, cloud compatibility, and vendor interoperability. Supports compliance requirements for financial services (CFTC, FINRA, SEC, MiFID II), emergency services (NENA i3), and PCI-DSS.

Keywords: SIPREC, Session Recording Protocol, RFC 7866, RFC 7865, SRS, SRC, call recording, VoIPmonitor SIPREC, siprec_bind, OpenSIPS siprec, Kamailio siprec, compliance recording, CFTC, FINRA, MiFID II, NENA i3, PCI-DSS

Key Questions:

  • How do I enable SIPREC in VoIPmonitor?
  • What is the difference between SIPREC and packet capture?
  • How to configure OpenSIPS or Kamailio for SIPREC with VoIPmonitor?
  • What ports need to be open for SIPREC?
  • Can VoIPmonitor use SIPREC and packet sniffing at the same time?
  • How does SIPREC help with CFTC/FINRA/MiFID II compliance?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=SIPREC&oldid=10747"