Overview of SIPREC architecture and Media Forking in RTPEngine and how we can use it in OpenSIPS sip proxy server.

1. SIP-Based Media
Recording (SIPREC)
and RTPEngine
Hossein Yavari
Oct. 2022

2. SIPREC
- RFC 7245 (https://www.rfc-editor.org/rfc/rfc7245)
- Using SIP to open a recording session and sending a copy of a media stream to a recording
device
- Terms:
- Session Recording Client (SRC): A SIP User Agent (UA) that is a specialized media server
- Session Recording Server (SRS): A SIP User Agent (UA) that acts as the source of the recorded
- media
- Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is
the subject of recording.
- Recording Session (RS): The SIP session created between an SRC and SRS to record a CS.
- Recording Metadata: The metadata describing the CS required by the SRS. This will include, for
example, the identities of users participating in the CS and dialog state.

3. Session Recording Architecture
B2BUA acts as SRC:

4. Session Recording Architecture (Cont.)
Endpoint acts as SRC:

5. Session Recording Architecture (Cont.)
MEDIACTRL acts as SRC:
• The MEDIACTRL architecture
[RFC5567] describes an
architecture in which an
Application Server (AS) controls a
Media Server (MS), which may be
used for purposes such as
conferencing and recording media
streams.

6. Session Recording Architecture (Cont.)
Conference Focus acts as SRC:

7. Establishing the Recording Session
- The SRC or the SRS may initiate the Recording Session.
- The Recording Session is independent of the CS that is being recorded at both the SIP dialog
level and the session level.
- Regular SIP/SDP capabilities should be used, and existing transcoding capabilities and media
encryption should not be precluded.
- SRS-Initiated Recording:
- Sends an INVITE request to the SRC, including indicating that the session is established to record the
associated media.
- Includes an SDP attribute of "a=recvonly" for each media line if the Recording Session is to be started
immediately or includes "a=inactive" if it is not ready to receive the media.

8. Media Stream Mixing
- In a basic session involving only audio, there are typically two audio/RTP streams between the
two UAs involved in transporting media in each direction.
- When recording this media, the two streams may be mixed or not mixed at the SRC before
being transmitted to the SRS.
- When they are not mixed, two separate streams are sent to the SRS, and the SDP offer sent to
the SRS must describe two separate media streams.
- In the mixed case, a single mixed media stream is sent to the SRS.

9. Recording Metadata
- https://www.rfc-editor.org/rfc/rfc7865.html
- The metadata is transported via SIP-based mechanisms as specified in: https://www.rfc-
editor.org/rfc/rfc7866.html

10. RTPEngine Media-Forking
and OpenSIP SIPREC
module

11. OpenSIPS SIPREC
- From SIP signaling perspective, the module does not change the call flow between the caller
and the callee.
- The call is established just as any other calls that are not recorded. But for each call that has
SIPREC engaged, a separate SIP session is started by the SRC (OpenSIPS) towards the SRS,
using the OpenSIPS Back-2-Back module.
- The INVITE message sent to the SRS contains a multi-part body consisting of two parts:
- Recording SDP - the SDP of the Media Server that will fork the RTP to the recorder.
- Participants Metadata - an XML-formatted document that contains information about the
participants. The structure of the document is detailed in RFC 7865.
- Module document: https://opensips.org/docs/modules/3.4.x/siprec.html
- Git: https://github.com/OpenSIPS/opensips/tree/master/modules/siprec

12. RTPEngine Media-Forking feature
- Tree type of messages:
- subscribe request:
- is used to request a subscription (i.e. receiving a copy of the media) to one or multiple existing call participants,
which must have been created either through the offer/answer mechanism, or through the publishing
mechanism.
- subscribe answer:
- This message is expected to be received after responding to a subscribe request message. The message should
contain the same to-tag as the reply to the subscribe request as well as the answer SDP in sdp.
- Unsubscribe:
- This message is a counterpart to the subsscribe answer to stop an established subscription. The subscription
to be stopped is identified by the to-tag.

13. References
• Session Recording Protocol: https://www.rfc-editor.org/rfc/rfc7866.html
• An Architecture for Media Recording Using the Session Initiation Protocol: https://www.rfc-
editor.org/rfc/rfc7245