SIPREC (Session Initiation Protocol Recording) is an IETF RFC that defines a standardised method for recording sessions in SIP-based networks. So, if you are a mobile or fixed operator, or both, SIPREC is likely to be the most suitable way of enabling a call recording service for your customers. It provides a standardised means of recording desired sessions – and replaces other methods which involved proprietary logic to cover different scenarios.
SIPREC was defined in RFC 7245 (related RFCs include 6341, 7866, and 7865). It offers an architecture for use alongside Session Border Controllers, and leverages a technique known as ‘media mirroring’. With media mirroring, the media to be recorded is essentially forwarded to the recording platform.
However, for this to function correctly and for all target sessions to be captured, interaction must take place between the platform and the SBC. That’s where SIPREC comes in, as it’s essentially a protocol that allows the different elements of the architecture to coordinate what and when recordings should take place, as well as to enable efficient transfer of metadata (phone numbers, start time, etc).
With SIPREC, there are two key functional entities: the Session Recording Client (SRC) and the Session Recording Server (SRS). To record a communication session, a recording session must be established between the SRC and the SRS. Then, to enable access to the recording, the metadata must be shared between the two.
The SIPREC protocol facilitates this, and thus enables the recording of voice calls, video calls, and other multimedia sessions by permitting recording systems to passively receive and record media streams without directly participating in the call setup or media negotiation process. It also enables recording solutions to be seamlessly integrated into SIP-based networks. This is important, because it allows operators to deliver recording at the network level – that is, without any requirements on user equipment.
Finally, the SBC deployed should also support SIPREC, so that it can, in turn, interact with the SRC. Because SIPREC is standardised, it should be possible to deploy any mix of compliant solutions, allowing the operator to choose the right SBC, SRC and SRS for the solution and service it intends to offer.
SIPREC has a number of distinguishing characteristics. These include:
As we noted earlier, session recording requires the establishment of a recording session between the communication system and recording system. This necessitates that information about the communication session (metadata) be shared between SRC and SRS. The SIPREC protocol uses SIP as the protocol with the process working as follows:
Gintel provides the SRC, which interacts with the SBC in SIPREC sessions. Based on media mirroring to the external platform using SIPREC, the Gintel solution is a stand-alone IMS application that can be deployed independent of other IMS applications and can coexist, for example with other B2B services. Recording can be invoked for either originating or terminating calls, or both.
When combined with an appropriate third-party SRS, a complete recording solution can be realised. Gintel’s SIPREC call recording solution has been deployed with several different vendor platforms, primarily to enable B2B call recording services offered by fixed and mobile operators.
Typically, the combined solution supports:
Session recording (and storage, processing, etc) is provided by a SIPREC-compliant third party). The Gintel solution passes the metadata to the chosen recording platform, and also determines whether the called or calling party calls should be recorded.
In SIPREC scenarios, Gintel thus acts as the SRC, the SRS is provided by a third party with interactions between the two. Importantly, the Gintel solution is fully standards complaints and as such will remain both forwards and backwards compatible with other services. This is also important if the core network architecture changes – by relying on Gintel for the key SRC functionality, the operator can safely evolve its solution set and also ensure compatibility with other services and scenarios.
Want to learn more about Gintel, our mission and our technology