assertion when the ACK response is recognized as a merged request #4203
Conversation
This file contains 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
sauwming
approved these changes
Dec 9, 2024
|
The ACK is not recognized as a correct answer to 200 OK and is treated as merged request because it does not have To tag (provided in the 200 response). It has nothing to do with the CANCEL (simultaneously or not). So I think the "dropped/unhandled" should be the proper behavior. |
nanangizz
reviewed
Dec 9, 2024
pjsip/src/pjsua-lib/pjsua_core.c
Outdated
|
|
||
| return PJ_TRUE; | ||
| PJ_LOG(4, (THIS_FILE, "Merged request detected (%s) (%s): %s from %s:%d", | ||
| dlg ? dlg->obj_name : NULL, |
There was a problem hiding this comment.
It is better "" or -no-dlg- rather than NULL for the %s, which may lead to undefined behavior.
|
OK, set -no-dlg- instead of NULL |
nanangizz
approved these changes
Dec 10, 2024
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.
pjsip tries to respond with 482 on any "receiving incoming requests" recognized as a merged request, but if that is ACK, calling
pjsip_endpt_respond() -> pjsip_endpt_create_response() raise folowing assertion in this last function:
/* Request MUST NOT be ACK request! */
PJ_ASSERT_RETURN(req_msg->line.req.method.id != PJSIP_ACK_METHOD,
PJ_EINVALIDOP);
If we consider ACK as a merged request, we should not issue an assertion, but can we consider ACK as a request (merged or not)?
I think this is invalid pjsip behavior, I added a check that the packet is not an ACK before calling pjsip_endpt_respond() (and made the "merged request detected" log message more informative).
This situation now results in a "dropped/not handled by any module" log message, but does not trigger an assertion.
But this is a hack...
See attached file with a trace of the real call: in-ack.txt
Remote side send us CANCEL (Frame 10), practically simulteniously with our OK (Frame 9). I am not quite sure, but received ACK (Frame 11) treated as merged request looks like the correct answer on our 200 OK (Frame 9).
I think we should recognize it as a such answer even after received CANCEL. But currently we start timer to retry OK sending, retransmit it during 30 sec and then send BYE.