Callfork fixes #7

Merged

laforge merged 2 commits from sur5r/yate:callfork-fixes into master

2023-10-03 09:02:04 +00:00

sur5r commented

2023-10-02 21:58:58 +00:00

Member

These fixes have been developed by eventphone during C3 events. See individual commit messages for explanation.

sur5r added 2 commits 2023-10-02 21:58:58 +00:00

63f61805a1

callfork: Fix error propagation

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.

746c12b2dc

Callfork: Inconsistent group progression

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.

laforge merged commit 7148da333f into master

2023-10-03 09:02:04 +00:00

laforge deleted branch callfork-fixes

2023-10-03 09:02:04 +00:00

laforge referenced this issue from a commit

2023-10-03 09:02:05 +00:00

Merge pull request 'Callfork fixes' (#7) from sur5r/yate:callfork-fixes into master

No reviewers

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: retronetworking/yate#7

No description provided.