Poc contributions #8
Open
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
If all fork children fail before any channel can be created, the fork will always fail with error code 500. However, we can have such a situation because all participants are offline and the routing returns the respective error code. In order to mitigate this, we update the error code of the call.execute message of the fork. So, in the case that all children fail before any channel can be established, the caller will see the error code of the last child. In an all-offline scenario this would be 404.
Callforks support three types of call legs: - regular - auxiliar - persistent These different types change the behavior of how groups progress. If no regular calls are left in a group, the fork progresses immediately to the next group, drops all auxiliar children and keeps the persistent ones. However, there is inconsistent behavior depending on whether the creation of a call leg is successful or not. Currently, the check if there are regular calls left in the current group is only implemented in lostSlave(). So, if you have a group with one persistent member (ringback) and one regular member, you can observe different behavior in the case that routing for the member fails and in the situation that the call is started but then rejected on a remote end. If the regular member is remote, forkSlave() will succeed and initiate a sip call. The callContinue() function will return. Then, the sip call might fail because the remote member is offline. Now lostSlave() is called, the module detects that this was the last regular member and immediately progresses to the next group. If the regular member, however, is local, the routing knows that the member is offline and fails. In this case forkSlave() will fail. Nonetheless, forks = 1 because creation of the persistent slave (ringback) was succesful. Consequently, the call continues but it is ringing nowhere. In case that the next group is timed, the caller will just hear the ringback for a while. If the next group isn't timed but expected to progress if all calls in the current group have failed, the call is actually stuck and the caller will hear the ringback indefinately while it is nowhere ringing. This patch fixes this behavior by checking if regular call legs are active before returning from callContinue(). If this isn't the case, it will trigger progression to the next group immediately.
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.
No description provided.