SIP PRACK/UPDATE Interworking Support in OpenSIPS 4.0

Introduction

One of the more stubborn SIP interop problems in modern networks is reliable provisional response handling, especially when bridging classic SIP deployments with IMS-oriented environments.

In IMS-heavy networks, RFC 3262 support is often assumed. That means 100rel, RSeq, RAck and PRACK are not optional extras anymore, but part of normal call establishment. On the other side of the wire, however, many SIP devices, SBC-adjacent applications, legacy PBXs or PSTN-facing SIP gateways either do not implement reliable provisional responses at all, or only implement them partially.

The result is familiar: one side expects PRACK, the other side does not know what to do with it, and call setup fails for reasons that have little to do with the actual service logic.

With OpenSIPS 4.0, we are bringing native PRACK interworking support into the dialog module, allowing OpenSIPS to actively bridge these capability gaps and help calls complete successfully across mixed SIP environments.

The support covers both UAC-side and UAS-side interworking:

• UAC-side: OpenSIPS generates PRACK towards the downstream side whenever it mandates reliable provisional handling.
• UAS-side: OpenSIPS terminates incoming PRACK itself and shields the far side from having to understand RFC 3262.

This is exactly the sort of feature that becomes increasingly important when OpenSIPS sits between IMS cores, access SBCs, application servers and less feature-complete SIP endpoints.

PRACK Interworking: Auto Mode

The easiest way to enable PRACK interworking in OpenSIPS 4.0 is the new auto mode.

In this mode, OpenSIPS detects reliable provisional replies within a dialog and automatically generates the required PRACK on the appropriate leg. This is particularly useful when OpenSIPS acts as an interworking SIP hop between a 100rel-aware side and another side that is less feature-rich, or when you simply want the feature with minimal scripting.

The configuration is intentionally simple. The relevant part is just enabling dialog support with the new “auto-prack” flag:

if (!create_dialog("auto-prack")) {
      send_reply(500, "Internal Server Error");
      exit;
  }

  if (!record_route()) {
      send_reply(500, "Internal Server Error");
      exit;
  }

  if (!t_relay())
      send_reply(500, "Internal Error");

That is the essential bit. Once a dialog is created with “auto-prack”, OpenSIPS can take care of PRACK generation automatically during early dialog establishment.

OpenSIPS 4.0 also adds dedicated control over the failure-handling policy in this area, so you can choose whether a PRACK failure should simply be observed or should actively result in dialog termination. For a more strict implementation on the UAC side (when OpenSIPS generates the PRACK), you can enable this new setting (default: false):

modparam("dialog", "auto_prack_hangup_on_failure", true)

So for many deployments, auto mode is the most natural starting point:

• clean enablement through create_dialog()
• very little script logic
• good interoperability out of the box

PRACK Interworking: Manual Mode

Of course, OpenSIPS would not be OpenSIPS without a more scriptable option!

The manual mode gives you full control over when and how PRACK should be generated or terminated. This is useful when you want custom signaling policy, special matching logic, or more advanced call handling around reliable provisional replies.

On the UAC side, a basic implementation can be as small as detecting a reliable provisional reply and sending a sequential PRACK yourself:

onreply_route[manual_prack] {
      if (!($rs >= 101 and $rs < 200))
          return;

      if (!list_hdr_has_option("Require", "100rel"))
          return;

      dlg_send_sequential("PRACK", "callee");
  }

That is already enough to cover the essential success path for PRACK generation.

Manual mode is also useful on the UAS side, where OpenSIPS can:

• add Require: 100rel
• synthesize RSeq
• validate RAck
• answer PRACK locally with 200 OK

In other words, manual mode gives you the full toolkit, while leaving policy in your hands. Without going too deep into code details, some of the concepts involved in the opensips.cfg scripting to achieve the 100% compliant manual PRACK implementation are:

• dialog values and watchdog-style checks
• local_route
• onreply_route
• dialog correlation
• helper headers for internal transaction handling
• mi_script
• delayed t_reply() logic

These building blocks allow OpenSIPS to go well beyond basic interoperability and move toward policy-driven interworking behavior.

Mid-Dialog UPDATE Interworking

Reliable provisional response handling is only one side of the interoperability story.

Another major pain point in mixed SIP environments is mid-dialog UPDATE interworking. IMS-oriented systems often rely on UPDATE for SDP refreshes and session changes, while other SIP endpoints or PSTN-adjacent systems may not support UPDATE at all, even though they can still handle a classic re-INVITE.

This is where OpenSIPS scripting becomes especially interesting.

Using dialog-aware routing logic, OpenSIPS can detect an incoming mid-dialog UPDATE, keep track of the original transaction, and trigger an opposite-leg in-dialog INVITE instead. If that re-INVITE succeeds, OpenSIPS can reply 200 OK to the original UPDATE. If it fails, OpenSIPS can reject the pending UPDATE accordingly and even decide to terminate the dialog from the middle if that is the desired service policy.

In other words, OpenSIPS can also act as an interworking signaling brain between:

• one side that speaks UPDATE
• another side that only understands re-INVITE

The starting point is to catch the UPDATE in your opensips.cfg and generate the outgoing re-INVITE transaction while keeping some data about the UPDATE transaction attached as a SIP header:

  if (has_totag() && is_method("UPDATE")) {
      if (!t_newtran()) {
          send_reply(500, "Internal Error");
          exit;
      }

      if (!dlg_send_sequential("INVITE", "caller", $rb, $ct,
      "X-TID: $T_id\r\nX-TOTAG: $tt\r\n")) {
          t_reply(500, "Interworking Failed");
      }

      exit;
  }

Afterwards, you can use a local_route to catch the INVITE and arm additional onreply_routes, or failure_route, to achieve the full desired signaling.

Pro Tip: If you really want to dig into details here, make sure to check out the full PRACK test suite added to sipssert-opensips-tests, with complete configuration examples across a multitude of scenarios.

See You at the Summit

PRACK interworking support in OpenSIPS 4.0 opens the door to much smoother SIP interoperability with IMS-oriented environments, while still preserving the flexibility that OpenSIPS users expect.

But more details at the OpenSIPS Summit conference in Bucharest, from April 28th to May 1st 2026!