Repository navigation
Conversation
🦋 Changeset detectedLatest commit: 491e261 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Friendly ping for review — this raises the SIP header value cap so long X-Twilio-CallToken headers (large Twilio call SIDs) aren't rejected; pairs with livekit/sip #822 which depends on it. Test and CLA are green on the current head. Could someone take a look when convenient? Happy to make any adjustments needed. |
b94ca3e to
2e63dda
Compare
2e63dda to
7dae06b
Compare
|
Hi @davidzhao — gentle nudge. This raises the SIP header value cap to 4 KB so large carrier tokens (e.g. Twilio call SIDs in X-Twilio-CallToken) aren't rejected — it unblocks livekit/sip #822, which is waiting on it. Tests and CI changes are in place; the only red check is |
|
Friendly maintainer ping (34+ days, last nudge Sep 27) — raises the SIP header value cap to 4 KB for carrier tokens like |
…ilio-CallToken Twilio's Immutable Call Forwarding flow requires X-Twilio-CallToken to be forwarded unchanged on the outbound leg. The token is opaque and carries SHAKEN/STIR + DIV PASSporTs, so it routinely exceeds the current 1024-byte cap and CreateSIPParticipant rejects the request with 'invalid header value for X-Twilio-CallToken: value too long (max 1024 characters)' before the INVITE is ever sent. RFC 3261 §7.1 bounds the message (8 KB datagram on UDP), not individual header values. 4096 keeps a single header from dominating a datagram while tolerating real carrier tokens; the character-set validation is unchanged. Fixes livekit#789
7dae06b to
491e261
Compare
Summary
CreateSIPParticipantrejects valid TwilioX-Twilio-CallTokenvalues over 1,024 bytes:Twilio's Immutable Call Forwarding flow requires this token to be forwarded unchanged on the outbound leg so the original caller ID can be presented. The token is opaque and may contain SHAKEN/STIR and DIV PASSporTs, so truncating it is not valid either.
Root cause
ValidateHeaderValueResultcaps every header value at 1,024 characters. RFC 3261 does not bound individual header values — §7.1 bounds the whole message (8 KB datagram over UDP, larger over TCP). The 1 KB figure is this codebase's own policy and sits below the size real carrier tokens reach.Fix
maxHeaderValueLength = 4096and reject values above it. 4 KB keeps a single header from dominating an 8 KB datagram while tolerating real-world carrier tokens. Character-set validation is unchanged.Fixes #789