Fix ACK using a random To tag instead of echoing the remote's - #317
Open
hainesdev wants to merge 1 commit into
Open
Fix ACK using a random To tag instead of echoing the remote's#317hainesdev wants to merge 1 commit into
hainesdev wants to merge 1 commit into
Conversation
Fixes tayler6000#312 [FIX] Fixed gen_ack generating a random To tag instead of echoing the one the remote UAS assigned in its 2xx response, per RFC 3261 17.1.1.3. The mismatched tag meant the remote couldn't match the ACK to its dialog, so it kept retransmitting the 2xx until it gave up and tore the call down. Confirmed live against a real Asterisk PBX: call rings, gets answered, then dies after ~30s instead of connecting.
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 #312
gen_ack()generated a brand-new random tag for the ACK'sToheader instead of echoing the tag the remote UAS assigned in its 2xx response. Per RFC 3261 17.1.1.3 the ACK must reuse that exact tag, or the remote can't match it to the dialog it created -- it just keeps retransmitting the 2xx (Timer G) until it gives up and tears the call down (Timer H).Confirmed live against a real Asterisk 22 / FreePBX 17 PBX with
pjsip set logger on: the call rang, was answered, and then hold music played and the call died a few seconds later instead of connecting -- the PBX trace showed it retransmitting the same 200 OK 11 times, each one followed by an ACK from our side that it never recognized as satisfying the transaction, before giving up.Fix mirrors the same tag-echoing pattern already used correctly elsewhere in this file (e.g.
gen_bye): userequest.headers["To"]["tag"]when present, fall back togen_tag()only if it's genuinely empty.