SIPREC with RTPEngine

RTPEngine is one of the best options among open-source solutions for RTP or media handling and it besides other platforms like Kamailio will give you many features or ready-to-go solutions.

When you are handling media sessions in IMS or any VoIP network, you should have a solution for recording, media barging or let’s say Lowful Interception (LI). LI in IMS has a long story and it is out of scope; for this post, we focus on call recording.

First of all, we need to what is SIPREC? I shared a ppt here that gives you overal info you need:

The ppt gives a good overview of what SIPREC is and how Kamailio and RTPEngine fit into this picture. But, what if you don’t use the Kamailio? How you can use RTPEngine features to implement media recording?

RTPEngine media forking feature let you fork active sessions to another destination that in our case we call SRS. The call recording server or SRS can send a command to RTPEngine through NG protocol. So, might it not be a SIP-aware server, but it should be able to handle RTP protocol and offer an SDP.

Media forking happens through the subscribe command, e.g. SRS sends a subscribe request command to RTPEngine and subscribes itself to the target call. You can see a sample payload below:

1
2
3
4
5
6
7
8

{
   "command": "subscribe request",
   "call-id": "call xyz",
   "from-tags": [
      "test"
   ],
   "transport protocol": "RTP/AVP"
}

When RTPEngine receives the command, it responds with SDP that includes a=sendonly attribute:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
   "result": "ok",
   "sdp": "v=0
         o=- ...
         s=rtpengine-11-2-0-0-0
         t=0 0
         m=audio 30160 RTP/AVP 96
         c=IN IP4 192.168.1.120
         a=rtpmap:96 opus/48000
         a=sendonly
         a=rtcp:30160
         m=audio 30172 RTP/AVP 96
         c=IN IP4 192.168.1.120
         a=rtpmap:96 opus/48000
         a=sendonly
         a=rtcp:30170",
   "from-tags": [
   "test"
   ],
   "to-tag": "9e2a2a7fc4d6..."
}

In the next step, SRS should send its SDP to RTPEngine through subscribe answer with a=recvonly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
   "command": "subscribe answer",
   "call-id": "call xyz",
   "to-tag": "9e2a2a7fc4d6...",
   "sdp": "v=0
            o=- 2345 2345 IN IP4 192.168.1.95
            s=-
            t=0 0
            m=audio 33345 RTP/AVP 96
            c=IN IP4 192.168.1.95
            a=rtpmap:96 opus/48000
            a=recvonly
            m=audio 33366 RTP/AVP 96
            c=IN IP4 192.168.1.95
            a=rtpmap:96 opus/48000
            a=recvonly"
}

After this SRS will receive the forked media RTP packets and then it can save it to file or prepare it for LI interfaces. Don’t forget that transcoding also is possible for forked media, when you ask it in subscribe answer SDP, very useful!