Repository navigation
fix(rpc): give a SIP request 3s for a SIP instance to claim it - #1846
Open
cosmin-staicu wants to merge 1 commit into
Open
cosmin-staicu wants to merge 1 commit into
cosmin-staicu wants to merge 1 commit into
Conversation
CreateSIPParticipant and TransferSIPParticipant are queue RPCs that need a claim: the caller publishes the request, one SIP instance takes the queue lock and publishes a claim back, and only then is the request granted. The SIP client never set a selection timeout, so psrpc's 1s default applied, and livekit-server builds this client without retries on purpose. A claim that lands after 1s fails the dial outright with "no response from servers". On the Redis bus that claim costs the SIP instance two round trips on pooled connections, the SetNX queue lock and the claim publish. After an idle stretch longer than the pool's idle limit both open fresh TLS connections first, which is when a dial has been seen to miss the window while the next one, moments later, goes through. NewSIPClientWithParams now puts a 3s selection timeout ahead of the caller's options, so a caller that sets its own still wins. The window only bounds how long an unclaimed request waits; the request is never sent again, so a longer one cannot place a call twice. A SIP instance that is really gone now fails in 3s instead of 1s. Signed-off-by: Cosmin Staicu <cosmin.staicu@uipath.com>
cosmin-staicu
force-pushed
the
fix/sip-client-claim-timeout
branch
from
October 17, 2026 11:01
f7a5043 to
3564cfb
Compare
🦋 Changeset detectedLatest commit: 3564cfb 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 |
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.
CreateSIPParticipantandTransferSIPParticipantare queue RPCs that need a claim: a SIP instance takes the queue lock and publishes a claim back before the request is granted. The SIP client sets no selection timeout, so psrpc's 1s default applies, and livekit-server builds this client without retries. A claim that arrives after 1s fails the dial with "no response from servers".On the Redis bus the claim costs the SIP instance two round trips on pooled connections, the SetNX lock and the claim publish. After an idle stretch longer than the pool's idle limit, both first open fresh TLS connections. That is when we have seen a dial miss the window while the next one, moments later, goes through.
NewSIPClientWithParamsnow puts a 3s selection timeout ahead of the caller's options, so a caller that sets its own still wins. The timeout only bounds how long an unclaimed request waits. The request is never resent, so a longer window can't place a call twice. A SIP instance that is really gone now fails in 3s instead of 1s.