SIP parser fails to handle IPv6 addresses in Via/Contact/From headers (strconv.Atoi error)

[arsenieciprian]

Summary

When a SIP INVITE arrives over TCP from an IPv6 endpoint (e.g. FreeSWITCH), livekit-sip logs failed to parse and silently drops the message without sending any response (no 100 Trying, no 486, nothing). The TCP connection stays open but the call never progresses.

IPv4 inbound calls on the same trunk work correctly.

Error

INFO  sip  failed to parse  {
  "caller": "transport<TCP>",
  "err": "strconv.Atoi: parsing \"67c:b0c:5::192]:5060\": invalid syntax: EOF on reading line",
  "data": "INVITE sip:+40215700020@callmanager.voxbee.ro;transport=tcp SIP/2.0\r\n
    Via: SIP/2.0/TCP [2001:67c:b0c:5::192];branch=z9hG4bKB5mrcD1BXK68a\r\n
    ...
    Contact: <sip:mod_sofia@[2001:67c:b0c:5::192]:5060;transport=tcp>\r\n
    From: \"+40710000010\" <sip:+40710000010@[2001:67c:b0c:5::192]>;tag=5gQH6Hrmc42Ua\r\n
    ..."
}

The parser attempts strconv.Atoi on "67c:b0c:5::192]:5060" — it appears the [ bracket is consumed but then the remaining IPv6 address + ] + :port is passed to the integer port parser, which fails.

Steps to Reproduce

1. Configure a FreeSWITCH (or any SIP UA) to send INVITEs over IPv6 TCP
2. Point it at livekit-sip on port 5060 via an IPv6 address
3. Trigger an inbound call

The INVITE will arrive (confirmed via tcpdump — TCP handshake completes, data is received), but livekit-sip will not respond.

Affected SIP Message

INVITE sip:+40215700020@callmanager.voxbee.ro;transport=tcp SIP/2.0
Via: SIP/2.0/TCP [2001:67c:b0c:5::192];branch=z9hG4bKB5mrcD1BXK68a
Max-Forwards: 67
From: "+40710000010" <sip:+40710000010@[2001:67c:b0c:5::192]>;tag=5gQH6Hrmc42Ua
To: <sip:+40215700020@callmanager.voxbee.ro;transport=tcp>
Call-ID: e0dcb959-a7b8-123f-4496-cafac563ef4b
CSeq: 112931612 INVITE
Contact: <sip:mod_sofia@[2001:67c:b0c:5::192]:5060;transport=tcp>
User-Agent: FreeSWITCH
Content-Type: application/sdp
Content-Length: 287

v=0
o=FreeSWITCH 1774938651 1774938652 IN IP6 2001:67c:b0c:5::192
s=FreeSWITCH
c=IN IP6 2001:67c:b0c:5::192
t=0 0
m=audio 32158 RTP/AVP 8 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

IPv6 addresses in SIP headers follow RFC 3261 §19.1.1 — they MUST be enclosed in [ ] when used in SIP URIs (e.g. [2001:db8::1]). The Via header address without a port ([2001:67c:b0c:5::192]) is also valid per RFC 3261.

Environment

• livekit/sip image: livekit/sip:latest (digest sha256:96ef59d461e692c43c77bfe2caa8b469e662e2cc1158082e3af5434184225897, built 2025-11-11)
• Network: host mode, listening on :::5060 (dual-stack)
• Caller: FreeSWITCH, transport TCP over IPv6
• Server OS: Linux (Debian), kernel dual-stack enabled (net.ipv6.conf.all.disable_ipv6=0, net.ipv6.bindv6only=0)
• IPv4 calls: work correctly on the same setup

Root Cause (hypothesis)

The SIP URI parser in livekit-sip does not correctly handle the [ipv6] bracket notation for hostnames. When parsing host:port from a SIP URI or header value, it appears to:

1. Find the opening [ and consume it (or skip to its content)
2. Then look for a : to split host/port — but IPv6 addresses contain multiple : characters
3. Attempt strconv.Atoi on everything after the first :, i.e. "67c:b0c:5::192]:5060", which fails

The fix should treat [...] as a single host token (per RFC 3261 / RFC 2732) and only split on the :port that follows the closing ].

Impact

Any deployment where the SIP provider or PBX sends traffic over IPv6 TCP is completely non-functional. Inbound calls are silently dropped with no SIP error response to the caller.

This affects production systems where ISPs or carriers prefer/require IPv6, or where the SIP trunk and livekit-sip are co-located on an IPv6-only or dual-stack network segment.

[arsenieciprian]

Update: confirmed on UDP transport as well

Tested with transport=udp — same behavior. The UDP parser also fails with the same error on the From header:

INFO  sip  failed to parse  {
  "caller": "transport<UDP>",
  "err": "parsing header failed line=\"From: \"+40710000010\" <sip:+40710000010@[2001:67c:b0c:5::192]>;tag=e2tgp5FmjmB4j\": strconv.Atoi: parsing \"67c:b0c:5::192]\": invalid syntax",
  "data": "INVITE sip:+40215700020@callmanager.voxbee.ro;transport=udp SIP/2.0\r\n
    Via: SIP/2.0/UDP [2001:67c:b0c:5::192];rport;branch=z9hG4bKe002HyKpme90D\r\n
    From: \"+40710000010\" <sip:+40710000010@[2001:67c:b0c:5::192]>;tag=e2tgp5FmjmB4j\r\n
    To: <sip:+40215700020@callmanager.voxbee.ro;transport=udp>\r\n
    Contact: <sip:mod_sofia@[2001:67c:b0c:5::192]:5060>\r\n
    ..."
}

tcpdump confirms the UDP INVITEs arrive at the server correctly ([2001:67c:b0c:5::192]:5060 → [2001:67c:b0c:5::130]:5060) — no response is ever sent back.

So the IPv6 bracket parsing bug affects both TCP and UDP transports. The parser fails on any SIP header that contains a [ipv6] URI (From, Via, Contact), not just Via.

Affected headers observed so far:

• TCP: Via: SIP/2.0/TCP [ipv6];branch=... — error on Via
• UDP: From: "..." <sip:user@[ipv6]>;tag=... — error on From

Both fail with strconv.Atoi being called on the IPv6 address content after the first :.

[dennwc]

We completely rely on sipgo for the SIP protocol parsing, so that might be an upstream issue.

[arsenieciprian]

Thanks for the pointer! I took a look at the sipgo source to verify.

The bug is actually in livekit-sip, not in sipgo.

sipgo's IPv6 parsing in parse_uri.go is correct — the uriStateHostIPV6() function properly handles bracket notation and only calls strconv.Atoi() on the actual port digits.

The issue appears to be in livekit-sip's own Normalize() method in pkg/sip/types.go:

func (u URI) Normalize() URI {
    if addr, sport, err := net.SplitHostPort(u.Host); err == nil {
        if port, err := strconv.Atoi(sport); err == nil {
            u.Host = addr
            u.Addr = netip.AddrPortFrom(u.Addr.Addr(), uint16(port))
        }
    }
    return u
}

When sipgo correctly parses a SIP URI with an IPv6 address, it populates u.Host = "[2001:67c:b0c:5::192]". Then livekit-sip's Normalize() attempts to re-parse this using net.SplitHostPort() on a string that ends up malformed, causing strconv.Atoi() to receive "67c:b0c:5::192]:5060" instead of just the port number.

So the fix should be in livekit-sip's URI normalization/conversion code, not upstream in sipgo.

[dennwc]

Good point, missed that one. We will fix it, thank you!

[arsenieciprian]

Hi @dennwc, just checking in — any update on this fix? We're still hitting the issue in production with IPv6 SIP trunks. Happy to test a patch if there's a branch in progress. Thanks!