Skip to content

rtpengine: async support for rtpengine_start_recording() - #4259

Open
zbyslb wants to merge 1 commit into
OpenSIPS:masterfrom
zbyslb:rtpengine-async-start-recording
Open

rtpengine: async support for rtpengine_start_recording()#4259
zbyslb wants to merge 1 commit into
OpenSIPS:masterfrom
zbyslb:rtpengine-async-start-recording

Conversation

@zbyslb

@zbyslb zbyslb commented Sep 14, 2026

Copy link
Copy Markdown

Summary

Exports rtpengine_start_recording() as an async command, making it usable with both async styles, exactly like the existing rtpengine_offer/answer/delete:

async(rtpengine_start_recording(), resume_route [, timeout]);
launch(rtpengine_start_recording() [, report_route]);

Typical use case: start call recording without blocking the SIP transaction, yet still learn in the resume/report route whether rtpengine actually accepted it — a middle ground between the fully synchronous call (blocks up to rtpengine_tout × rtpengine_retr) and fire-and-forget (no feedback at all).

Implementation

A thin wrapper, rtpengine_start_recording_af(), feeds OP_START_RECORDING into the existing rtpe_function_call_async() machinery — per-command socket, cookie, timeout handling and reply processing all come for free. Two small adjustments were required:

  1. Skip the mandatory SDP extraction. rtpe_function_call_async() unconditionally calls extract_body() for any op != OP_DELETE, but recording commands carry no SDP and are typically fired on in-dialog requests without a body (the extraction would fail). The wrapper passes an empty str as the body, which turns the extraction into a no-op (and rtpe_function_call_prepare() only attaches "sdp" for offer/answer anyway).

  2. Tighten the reply-body condition in resume_async_send_rtpe_command(). It treated every non-delete reply as carrying an "sdp" field to substitute into the message, failing the whole command when the field is absent. A recording reply only carries the result. The condition is now exactly the set of ops that do return a new SDP (offer/answer/subscribe-answer) — a no-change for the three already-exported async commands.

The synchronous rtpengine_start_recording() stays available and unchanged; the async variant is only picked up when the function is wrapped in async()/launch().

Note

This touches the same function as #4258 (resume_async_send_rtpe_command, different hunk) — trivially rebaseable in either order.

Export rtpengine_start_recording as an async command, so it can be
used both as:

  async(rtpengine_start_recording(...), resume_route [, timeout]);
  launch(rtpengine_start_recording(...) [, report_route]);

just like rtpengine_offer/answer/delete. The wrapper reuses the
whole rtpe_function_call_async() machinery (per-command socket,
cookie, timeout handling).

Two adjustments were needed along the way:

* rtpe_function_call_async() unconditionally extracts an SDP body for
  any op != OP_DELETE, but recording commands carry no SDP and are
  typically fired on in-dialog requests without a body - so the
  wrapper passes an empty body str, which makes the extraction a
  no-op.

* resume_async_send_rtpe_command() treated every non-delete reply as
  carrying an "sdp" field to replace the message body with; a
  recording reply only carries the result, so the condition is
  tightened to exactly the ops that return a new SDP
  (offer/answer/subscribe-answer). This is a no-change for the
  existing three exported async commands.

The sync (blocking) rtpengine_start_recording() remains available
unchanged; the async version is only picked up when the function is
wrapped in async()/launch().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants