Skip to content

[FEATURE] add wildcard support (*) to mc_compact() to preserve unlisted headers instead of deleting them #3999

Description

@ccppprogrammer

Is your feature request related to a problem? Please describe.

Currently, the mc_compact() function uses a strict whitelist approach. It accepts a list of header names separated by a pipe character (|). Any SIP header present in the message that is not explicitly included in this whitelist and is not predefined is automatically deleted during the compaction process.
While this works well for strict minimization, it creates challenges when we want to compact the standard RFC-defined headers (like Via, From, To, Contact, Content-Length) but still preserve custom or external headers (like X- headers, P-Charging-Vector, etc.) without knowing their names in advance.

Describe the solution you'd like

I propose adding wildcard support (specifically using the * character) to the first parameter of the mc_compact() function.

  • Current behavior: mc_compact("Max-Forwards|P-Asserted-Identity") -> Compact predefined short forms, whitelist Max-Forwards and P-Asserted-Identity. Deletes everything else.
  • Proposed behavior: mc_compact("*") -> Compacts predefined short forms. Keeps all other headers in their original, uncompacted form instead of deleting them.
    If a standalone * is passed, or if * is part of the pipe-separated string, the module should treat it as an instruction to bypass the deletion of unlisted headers.

Implementation

  • Component:
  • Type:
  • Name:

Describe alternatives you've considered

Alternatively, a new optional flag parameter could be added to the function to change the behavior from "drop unlisted" to "keep unlisted", but adding * directly to the whitelist string feels more intuitive and maintains backward compatibility.

Additional context

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions