Fix gen_call_id producing the identical Call-ID across process restarts - #318
Open
hainesdev wants to merge 1 commit into
Open
Fix gen_call_id producing the identical Call-ID across process restarts#318hainesdev wants to merge 1 commit into
hainesdev wants to merge 1 commit into
Conversation
Fixes tayler6000#316 [FIX] Fixed gen_call_id deriving the Call-ID from a hash of an in-process counter, which restarts at the same value every time a new SIPClient is constructed. Short-lived processes (register, place one call, exit) generated an identical Call-ID on every run, which a server still holding a stale dialog under that Call-ID then treated as a malformed retransmission instead of a new call. Switched to uuid.uuid4(), which needs no cross-run state to stay unique.
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
1 participant
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.
Fixes #316
gen_call_id()derived the Call-ID fromhashlib.sha256(str(self.callID.next())), whereself.callIDis aCounterthat restarts at the same initial value every time aSIPClientis constructed. Any short-lived process (register, place one call, exit) generates the identical Call-ID on every run.If the server still has any memory of a dialog under that Call-ID from a previous run, the new INVITE gets misidentified as belonging to the old dialog instead of being a fresh call. Confirmed live against Asterisk via a PBX-side trace, this showed up two ways depending on timing:
400 Bad Request(Warning: Retransmission with different CSeq) -- the new INVITE got matched against the old dialog's last-seen CSeq.486 Busy Hereon a retry with the same Call-ID -- the callee looked busy because the stale dialog was still occupying it, when it wasn't actually busy.Fix switches to
uuid.uuid4(), which needs no persisted/cross-run state to guarantee uniqueness (uuidis already imported inSIP.py).