feat: tolerate bare LF line endings in SIP header parsing

[HectorMalot]

Summary

Some PBX stacks emit \n instead of \r\n for custom headers. This causes the parser to bleed past the header/body boundary and attempt to parse SDP body lines as SIP headers, producing errors like: field name with no value in header: "v=0"

Real-world example:

  Content-Length: 227\r\n
  X-Custom-One: value\n
  X-Custom-Two: value\n
  \r\n // <-- this \r\n is not parsed as the header-body boundary, but as the termination of X-Custom-One.
  v=0\r\n
  ...

Changes

• nextLine() — scan for whichever comes first: \r or \n. If \r is found first, use the existing CRLF path (including ErrParseLineNoCRLF for bare CR). If bare \n is found first, treat it as a line terminator and consume 1 byte.
• parseStartLine() — extend the stream-mode leading-whitespace skip to also strip bare \n, not just \r\n pairs.

Backwards compatibility

Messages that currently parse successfully with \r\n are unaffected. The new code path only activates when \n appears before \r. Messages that currently fail (like the example above) will now succeed.

Notes

The RFC 4475 'A Short Tortuous INVITE' test was previously parsing a multi-line header because the bare \n in the source of the sipgo tests allowed the current parser to continue with the next line. But, this is not in line with the spec, RFC 3261 sec 7.3.1 specifies: Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT).. Header folding is currently not implemented in Sipgo's header parsing (and fairly uncommon anyway). I'm happy to provide this in a follow-up PR if desired.

This does not affect testing. The torture test is disabled and header folding is not implemented at the parser level regardless.

[emiago]

Hi @HectorMalot . What are these stacks, and why trying make lib to go out of RFC?
Can you name reason why this stacks are doing that. Could be some bad configuration on their side?

[HectorMalot]

Have responded in the related issue in the tracker. Let’s pause this PR until discussion is resolved.