HELP-19729: handle rapid carrier retry that leaves cf_exe processes #6702
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
There is potential for a callflow executor leak when sending a default error response. In the field, we found inbound calls that were forwarded to a number which canceled the request almost immediately. When this happens, callflows gets a message back from stepswitch that the bridge was unsuccessful, then looks up the children in the callflow to see if any handle that specific hangup cause. In this case (and most configurations) there are no special branches so it performs a default action which is to send back a SIP error message. However, while that process is happening, FreeSWITCH has already forwarded the cancel from the B leg back to the A leg and out to the carrier. The particular carrier in this incident then immediately retries the same call in another zone. When that call gets created in the other zone, the ecallmgr call control usurps any other call control processes for that call id, terminating the ecallmgr call control in the first zone. It is only then that the first callflow sends the command to publish the SIP error, but with no ecallmgr control process in that zone anymore, nothing is there to process it. Callflows then waits indefinitely to hear back if the SIP error message was processed. As a general avoidance of similar situations the all infinite wait times in call command have also been reduced to one day by default, however if the cluster is servicing things like turret phones they can set it back to infinity.
jamesaimonetti
force-pushed
the
HELP-19729
branch
from
74ec8df
to
a1d4ef8
Compare
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.
There is potential for a callflow executor leak when sending a default error response. In the field we found inbound calls that were forwarded to a number which canceled the request almost immediately. When this happens callflows gets a message back from stepswitch that the bridge was unsuccessful then looks up the children in the callflow to see if any handle that specific hangup cause. In this case (and most configurations) there are no special branches so it performs a default action which is to send back a SIP error message. However, while that process is happening FreeSWITCH has already forwarded the cancel from the B leg back to the A leg and out to the carrier. The particular carrier in this incident then immediately retries the same call in another zone. When that call gets created in the other zone the ecallmgr call control usurps any other call control processes for that call id, terminating the ecallmgr call control in the first zone. It is only then that the first callflow sends the command to publish the SIP error but with no ecallmgr control process in that zone anymore nothing is there to process it. Callflows then waits indefinitely to hear back if the SIP error message was processed.
As a general avoidance of similar situations the all infinite wait times in call command have also been reduced to one day by default, however if the cluster is servicing things like turret phones they can set it back to infinity.