Replies: 2 comments
-
|
Thanks for the detailed diagnosis. The fix looks good. Would you mind submitting a PR? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thank you very much for checking. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi SIPSorcery team,
First of all, thank you for providing and maintaining such a fantastic OSS library. It has been incredibly helpful for studying and prototyping SIP applications!
Goal of this question
I am experiencing an issue where the event triggered upon cancelling an outgoing call (INVITE) changes depending on whether the cancellation occurs before or after 32 seconds have passed since the initial INVITE.
I would like to know if this is the intended behavior by design, or if it is an unintended side effect of the transaction cleanup logic.
Environment
What I did (Steps to reproduce)
I created a simple SIP client that sends an
INVITEand waits in theRingingstate. I then compared the behavior of cancelling the call (CancelCall()) in two scenarios:Actual behavior
When cancelling before 32 seconds, the
487 Request Terminatedresponse matches the INVITE transaction, and the call ends gracefully (UACInviteTransactionFinalResponseReceivedevent is triggered).However, when cancelling after 32 seconds, the INVITE transaction seems to be removed immediately upon cancellation, causing the subsequent
487response to be unmatched, which leads to a different event (SIPTransportResponseReceived) being triggered.Logs (Before 32s):
Logs (After 32s):
Proposed fix
Upon investigating the source code, I found that in
SIPTransactionEngine.cs, transactions are cleaned up based onCreated >= m_t6(where T6 is 32 seconds). When a call is cancelled after 32 seconds, sinceCreatedis already older than T6, it gets immediately removed by the engine's cleanup loop.The state becomes
Cancelled, but it seems this issue occurs because there is no specific handling for theCancelledstate.To prevent this, I tried modifying the logic to track the cancellation time (
CancelledAt) and keep the transaction alive for a short period after cancellation so it can catch the487response.Modifications:
CancelledAtproperty toSIPTransaction.csand set it when the state changes toCancelled.SIPTransactionEngine.csto checkCancelledAtinstead ofCreatedforCancelledtransactions.SIPTransaction.cs
Before
After
SIPTransactionEngine.cs
Before
After:
Behavior after applying the fix (Logs)
After applying this fix, cancelling after 32 seconds behaves exactly the same as cancelling before 32 seconds. The
487response is correctly matched, and the call ends gracefully (UACInviteTransactionFinalResponseReceivedevent is triggered).Logs (After fix, >= 32s):
Is this behavior around the 32-second boundary intended? Or would a fix similar to the one above be considered desirable?
Thank you for your time and assistance!
Finally, I am sharing the code used for this validation.
Code used for validation
Beta Was this translation helpful? Give feedback.
All reactions