Reduce string allocations

[paulomorgado]

Summary

This PR reduces temporary string generation across SIP, RTSP, SDP, RTP, WebRTC, and related example/test code paths. The changes replace allocation-heavy parsing and comparison patterns with ordinal string comparisons, ReadOnlySpan<char> slicing, destination-span split buffers, and more efficient serialization patterns.

The intent is to preserve existing behavior while reducing avoidable allocations in protocol parsing and message formatting hot paths.

Part of: #1434

Why

Protocol parsing in this library runs frequently and often on network-facing hot paths. Several existing patterns created unnecessary intermediate strings or arrays while parsing or comparing protocol text:

• ToUpper() / ToLower() before comparison
• Trim() and Substring() for short-lived parser slices
• string.Split(...) where only a few fields are needed
• Regex usage for fixed-format parsing or header normalization
• Repeated += string concatenation while serializing headers and SDP blocks
• Culture-sensitive or allocation-producing string comparisons where ordinal protocol comparisons are intended

These patterns increase GC pressure and make hot-path parsing more expensive than necessary. They can also obscure the intended comparison semantics, especially for protocol tokens where ordinal comparisons are the correct behavior.

What changed

String comparisons

Replaced case-normalizing comparisons such as:

• value.ToUpper() == ...
• value.ToLower() == ...
• value.ToUpperInvariant().StartsWith(...)
• value.ToLowerInvariant().Contains(...)

with explicit ordinal comparisons, primarily:

• StringComparison.Ordinal
• StringComparison.OrdinalIgnoreCase

This avoids temporary strings and makes protocol comparison semantics explicit.

Span-based parsing

Reworked many parser paths to operate on ReadOnlySpan<char> instead of repeatedly materializing strings.

This includes parsing in:

• SIP headers, requests, responses, URIs, parameters, and authorization digests
• RTSP headers, messages, requests, responses, and URLs
• SDP descriptions, media announcements, RTP maps, FMTP attributes, crypto attributes, and connection information
• Selected RTP, WebRTC, ICE, system, example, and test code paths

The parser logic now generally slices spans and only converts back to string at API/storage boundaries where a string is actually required.

Split allocation reduction

Replaced several string.Split(...) usages with span-based splitting.

For fixed-shape parsing, the code now uses destination-span split buffers such as:

Span<Range> ranges = stackalloc Range[3];
var count = source.Split(ranges, '=');

This preserves the original “exactly N parts” behavior without allocating a string array or intermediate string segments.

Where appropriate, split options are used to preserve intended trimming/removal behavior without extra Trim() calls, such as SDP line splitting with remove-empty and trim semantics.

Trim and substring reduction

Replaced parser-local Trim() and Substring() usage with span slicing and span trimming.

This avoids creating temporary strings for values that are only needed for comparison, branching, or short-lived parsing decisions.

Strings are still materialized when they are stored in public object properties, dictionaries, collections, or returned through existing APIs.

Regex removal in fixed-format hot paths

Removed regex usage from several parser paths where the format is fixed and can be parsed directly.

Notable examples include:

• SIP/RTSP header unfolding
• SDP fixed-format field parsing
• Digest/header parsing patterns

These paths now use direct span scanning/slicing instead of regex match objects and replacement strings.

Serialization allocation reduction

Reworked repeated string concatenation in message serialization paths.

Changes include:

• Using StringBuilder for repeated line/block construction
• Using interpolated strings for fixed-format output
• Avoiding long chains of + concatenation where interpolation is clearer and lets the compiler choose the appropriate lowering

This primarily affects SIP, RTSP, and SDP serialization code.

Compatibility support

Added Polyfill support and updated LangVersion to 14.0 so newer APIs and compiler features can be used consistently across the library’s target frameworks.

This makes span/range/split-based parsing available in cross-targeted code while keeping the implementation aligned with modern C# syntax and compiler behavior.

How

The implementation follows a few consistent patterns:

1. Use ordinal comparisons instead of allocating normalized-case strings.
2. Parse protocol text as spans and delay string creation until necessary.
3. Use Span<Range> / stackalloc split buffers for small fixed-field parsing.
4. Use split options where they preserve existing trim/remove-empty behavior.
5. Replace fixed-format regex parsing with direct span-based parsing.
6. Use StringBuilder for repeated serialization and interpolated strings for fixed-format output.
7. Keep externally visible behavior and string-backed object models unchanged.
8. Use Polyfill plus C# 14 compiler support to make newer APIs and language features available consistently across target frameworks.

Validation

Validated with:

• Release build of src\SIPSorcery\SIPSorcery.csproj
• Focused parser/unit test runs covering the changed SIP/RTSP/SDP parsing paths
• Whitespace/diff validation before commit

Some broader test runs may still be affected by unrelated networking/environment issues.

[sipsorcery]

This PR introduces some readbility issues in places. Replacing case statements with large if/else blocks is not really desireable.

In other cases if the code is going to be changed it should go further and make use of new built in methods.

For example, changing:

m_sipCallDescriptor.AuthUsername == null || m_sipCallDescriptor.AuthUsername.Trim().Length <= 0

to:

m_sipCallDescriptor.AuthUsername == null || m_sipCallDescriptor.AuthUsername.AsSpan().Trim().Length <= 0

would be better as:

string.IsNullOrWhiteSpace(m_sipCallDescriptor.AuthUsername)

[paulomorgado]

This PR introduces some readbility issues in places. Replacing case statements with large if/else blocks is not really desireable.

At the moment, C#/.NET is not able to use switch for performant ordinal ignore case matching in a performant way.

I'll try to come up with something that makes this more concise.

In other cases if the code is going to be changed it should go further and make use of new built in methods.

For example, changing:

m_sipCallDescriptor.AuthUsername == null || m_sipCallDescriptor.AuthUsername.Trim().Length <= 0

to:

m_sipCallDescriptor.AuthUsername == null || m_sipCallDescriptor.AuthUsername.AsSpan().Trim().Length <= 0

would be better as:

string.IsNullOrWhiteSpace(m_sipCallDescriptor.AuthUsername)

OOPS! Missed those ones. I'll do another pass.

[paulomorgado]

@sipsorcery,

I reverted back to switch, and used string.IsNullOrWhiteSpace(...).

I have a little devil screaming in the back of my mind to create EqualsOic extension methods to use StringComparison.OrdinalIgnoreCase and make the code less dense.

[sipsorcery]

The case statement could be kept clean and readable by just changing the switch to: switch(command.ToLowerInvariant())

[sipsorcery]

The original swtich could be left in place, and still get the benefit of the suggestion, by doing:

switch (args[0].ToLowerInvariant())
    {
        case FFMPEG_VP8_CODEC:
        case FFMPEG_VP9_CODEC:
...

[paulomorgado]

args[0].ToLowerInvariant() this may unnecessarily allocate a string,

[sipsorcery]

I think an extension method for this is justified (as per your main comment) given the frequency of use and the fact it's a bit of a mouthful.

[paulomorgado]

I tried to optimize strings as much as possible in this PR.

I'm sure more pattern will be uncovered.

I'd like propose other optimizations but, as you mention, these can become large PRs

[sipsorcery]

The case could be kept here as well by using the ToLowerInvariant() in the original swtitch.

[sipsorcery]

I agree with the improvements in this PR but it's big and touches some very fundamental classes. Can it be split up even further. The string formatting on all the demo apps and tests are low risk and could be put in a separate PR. The changes to the core SIP classes are the biggest risk and they should be separated into their own PR.

[paulomorgado]

@sipsorcery

I'm creating a PR for the changes under test and examples directories.

What is your plan after that?

[sipsorcery]

@sipsorcery

I'm creating a PR for the changes under test and examples directories.

What is your plan after that?

Do you mean as far as merging? I don't see any issues merging the changes in the test and examples directories.

If one of the PR's was solely for string formatting and spacing that would aslo be straight forward to verify and merge.

The bigger changes, particulatly in the SIPSorcery/core directory, are the ones that will need the most thorough testing and I'd plan to test them with as many of the SIP examples as practicable.

[paulomorgado]

@sipsorcery
I'm creating a PR for the changes under test and examples directories.
What is your plan after that?

Do you mean as far as merging? I don't see any issues merging the changes in the test and examples directories.

If one of the PR's was solely for string formatting and spacing that would aslo be straight forward to verify and merge.

The bigger changes, particulatly in the SIPSorcery/core directory, are the ones that will need the most thorough testing and I'd plan to test them with as many of the SIP examples as practicable.

• Reduce string allocations #1639 - Use explicit string comparisons in tests and examples
• Reduce string allocations in sys helpers #1644 - Reduce string allocations in sys helpers
• Modernize SIP string handling #1645 - Modernize SIP string handling

[paulomorgado]

Hey @sipsorcery, is this small enough now, or do you want more PRs extracted out of this?