Subscribe/Publish + Recording

[John Burke]

Hey All,

We are trying to setup some dedicated recording servers by forking the media stream from Proxy A to Proxy B (recorder).  Currently trying to do so via the subscribe/publish messages in the following order:

1. subscribe request to Proxy A.

{
  "sdp": "v=0\r\no=- 7286924450212365225 7286924450212365225 IN IP4 192.168.26.242\r\ns=rtpengine-10-5-6-0-0-mr10-5-6-0\r\nt=0 0\r\nm=audio 10426 RTP/AVP 0\r\nc=IN IP4 192.168.26.242\r\na=rtpmap:0 PCMU/8000\r\na=sendonly\r\na=rtcp:10427\r\nm=audio 10436 RTP/AVP 0\r\nc=IN IP4 192.168.26.242\r\na=rtpmap:0 PCMU/8000\r\na=sendonly\r\na=rtcp:10437\r\na=ptime:20\r\n",
  "from-tags": [
    "uNJNw6PLT",
    "eZND0H51arUgr"
  ],
  "to-tag": "4e07b5bb30c559caded95804dcf31f8f5e7d495c079c7f9f039d73d1ddf7316b",
  "result": "ok"
}

2. publish to Proxy B with SDP from (1) and record-call flag.

{
  "command": "publish",
  "sdp": "v=0\r\no=- 7286924450212365225 7286924450212365225 IN IP4 192.168.26.242\r\ns=rtpengine-10-5-6-0-0-mr10-5-6-0\r\nt=0 0\r\nm=audio 10426 RTP/AVP 0\r\nc=IN IP4 192.168.26.242\r\na=rtpmap:0 PCMU/8000\r\na=sendonly\r\na=rtcp:10427\r\nm=audio 10436 RTP/AVP 0\r\nc=IN IP4 192.168.26.242\r\na=rtpmap:0 PCMU/8000\r\na=sendonly\r\na=rtcp:10437\r\na=ptime:20\r\n",
  "call-id": "n8TvalVb9o",
  "from-tag": "uNJNw6PLT",
  "flags": [
    "record-call"
  ]
}

3. subscribe answer to Proxy A with SDP from (2).

{
  "command": "subscribe answer",
  "call-id": "n8TvalVb9o",
  "to-tag": "4e07b5bb30c559caded95804dcf31f8f5e7d495c079c7f9f039d73d1ddf7316b",
  "sdp": "v=0\r\no=- 7286924450212442585 7286924450212442585 IN IP4 192.168.26.246\r\ns=rtpengine-10-5-6-0-0-mr10-5-6-0\r\nt=0 0\r\nm=audio 10032 RTP/AVP 0\r\nc=IN IP4 192.168.26.246\r\na=rtpmap:0 PCMU/8000\r\na=recvonly\r\na=rtcp:10033\r\nm=audio 10050 RTP/AVP 0\r\nc=IN IP4 192.168.26.246\r\na=rtpmap:0 PCMU/8000\r\na=recvonly\r\na=rtcp:10051\r\na=ptime:20\r\n"
}

The media appears to be setup correctly, as we can see RTP flowing from Proxy A -> Proxy B. However, it doesn't look like the recording logic takes affect.  After poking around the code a bit, it also doesn't seem that the recording logic is in the call_publish_ng func.  Is recording via publish supported right now? And if not, would it be as simple as adding the logic to the call_publish_ng func?

Thanks,

John

[John Burke]

I was able to get the recording setup by manually invoking the start recording command (with the proc recording method). However, the recording file is always empty. I think the issue appears to be that the kernel module blackholes the media stream since there isn't a sink, and the RTP packets never reach the recording-dameon.  Maybe this is a feature request?

cat /proc/rtpengine/0/list
local inet4 192.168.26.246:10000
    stats:                    0 bytes,                    0 packets,                    0 errors
    SSRC in: bfb74f2
    option: non forwarding
    option: blackhole
local inet4 192.168.26.246:10014
    stats:                    0 bytes,                    0 packets,                    0 errors
    SSRC in: b12dcb36
    option: non forwarding
    option: blackhole

[Richard Fuchs]

On 09/10/2023 10.46, [EXT] John Burke wrote:

I was able to get the recording setup by manually invoking the start recording command (with the proc recording method). However, the recording file is always empty. I think the issue appears to be that the kernel module blackholes the media stream since there isn't a sink, and the RTP packets never reach the recording-dameon.  Maybe this is a feature request?

Yes, this isn't exactly a supported use case (although an interesting idea). It can probably be made to work without too much trouble (famous last words), perhaps just by moving the handling of the blackhole target around. Feel free to play with it if you're so inclined.

Cheers

[John Burke]

Thanks Richard. I did get a chance to play around a bit with the blackhole logic and just put in a PR.  TBH I'm not all that familiar with the blackhole functionality, but all of my unit tests were passing :)

Thanks,

John

[089 qqy]

Any updates on the issue? I'm having a similar problem—my service is for recording, which only receives RTP streams and then records them.

The approach I am testing is:

1. Use publish to enable rtpengine to receive RTP from the remote sender.

2. Use the start recording command to start recording.

Minimal JSON example using publish:

// Publish to start receiving RTP from a remote sender
{
  "command": "publish",
  "call-id": "1234567890@localhost",
  "from-tag": "from1234",
  "to-tag": "to1234",
  "sdp": "v=0\r\n" +
         "o=- 0 0 IN IP4 192.168.1.103\r\n" +
         "s=RTP Test\r\n" +
         "c=IN IP4 192.168.1.103\r\n" +
         "t=0 0\r\n" +
         "m=audio 5004 RTP/AVP 0\r\n" +
         "a=rtpmap:0 PCMU/8000\r\n" +
         "a=recvonly\r\n",
  "record-call": "yes"
}

// Start recording explicitly (if needed)
{
  "command": "start recording",
  "call-id": "1234567890@localhost"
}

// Later, delete the call
{
  "command": "delete",
  "call-id": "1234567890@localhost",
  "from-tag": "from1234",
  "to-tag": "to1234"
}

Issues observed:

• PCAP files are successfully generated, but rtpengine-recording does not seem to process them at all.

• No WAV files are generated.

• Metadata files appear abnormal and do not contain SDP information. Example:

···

/record/rtpengine/pcaps/1234567890%40localhost-3a461f026ea5e2da.pcap 

Timestamp terminated ms(first monologue): 1763032735483.400 

call start time: 2025-11-13T19:18:07 

call end time: 2025-11-13T19:18:55

···

Additionally, I configured rtpengine-recording’s spool-dir to point to the same path as recording-dir in the rtpengine configuration.

• Is this correct?

• Or should it point to the metadata subdirectory instead?

Any guidance on how to properly configure a receive-only recording setup with rtpengine would be greatly appreciated.

Thanks!