fix(sip): route in-dialog requests through the proxy's Record-Route path, not back at LiveKit-SIP - #822
Open
rkfshakti wants to merge 4 commits into
Open
Conversation
…op proxies swapSrcDst converts the Record-Route set to Route headers with PrependHeader, which reverses a set that was already reversed for the UAS direction — restoring wire order. With a multi-hop proxy in the path (e.g. Avaya Session Manager) that left our own Record-Route as the hop the proxy forwards to: the proxy stripped its entry and routed the REFER back to LiveKit-SIP, which rejected it with 405 and the transfer never completed. Append the Route entries in stored order instead, and update TestRouteSet's UAS expectation to the RFC-correct reversed order (RFC 3261 §12.1.1, §16.12.1.2). Fixes livekit#771
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #822 +/- ##
==========================================
+ Coverage 65.25% 73.53% +8.28%
==========================================
Files 51 43 -8
Lines 6588 7498 +910
==========================================
+ Hits 4299 5514 +1215
- Misses 1915 1984 +69
+ Partials 374 0 -374 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Author
|
The multi-proxy review finding is fixed on b110feb: inbound UAS BYE/REFER now builds its Route set from the original INVITE Record-Route headers in wire order, excludes the locally inserted Record-Route, and verifies both header order and transport destination. The focused route test passes repeatedly and all checks are green. A re-review would be appreciated; happy to make any further changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TransferSipParticipantfails against a multi-hop proxy (Avaya Session Manager): the out-of-dialog REFER gets aRouteheader pointing at LiveKit-SIP's own address instead of the proxy's Record-Route path. The proxy dutifully forwards to LiveKit-SIP, which doesn't recognize it as a valid inbound request and rejects with 405 — the transfer never completes. Transfers work fine against a direct peer.Root cause
For an in-dialog UAS request, the dialog's Record-Route set must be applied reversed (RFC 3261 §12.1.1 / §16.12.1.2).
NewReferRequest/NewByeRequestalready do that reversal when building the request — appending the response's Record-Routes in reverse order as the request's Record-Route set.swapSrcDstthen converts that set to Route headers withPrependHeaderper entry — which reverses it a second time, restoring wire order. With a multi-hop proxy, the resulting Route set ends with our own Record-Route as the hop the proxy forwards to: the proxy strips its entry and bounces the REFER back to LiveKit-SIP → 405.Fix
Append the Route entries in stored order (they are already correctly reversed for the UAS direction). Also fix
TestRouteSet's UAS expectation to the RFC-correct reversed order (it was asserting the buggy wire-order).[ours, proxy]— we route through the proxy once, it forwards to the peerFixes #771