1. Brekeke Product Name and Version:
Brekeke SIP Proxy Server 3.14.5.17
2. Java version:
11.0.19
3. OS type and the version:
RHEL 7.9
4. UA (phone), gateway or other hardware/software involved:
N/A (tested with Avaya and various other SIP implementations)
5. Your problem:
Setup: Two Brekeke SIP Proxy Servers running with mirroring/redundancy for HA.
Event: One of the proxy servers is rebooted (reboot or power failure, etc).
Observed outcome:
Ongoing/active calls remain up, however no longer appear under Active Sessions on the rebooted/restarted mirror half. Active calls do still show normally on the mirror half that was not rebooted/power cycled. If the secondary is also power cycled, then the call stays active but disappears from Active Sessions entirely on either mirror half.
Expected outcome:
Ongoing/active calls remain up and are listed in Active Sessions when the peer rejoins the mirror. Ongoing calls show under Active Sessions on one or both mirror servers.
This also occurred in a previous point release upgrade between 3.12.1.5 to 3.12.2.2, but was fixed in 3.13.0.0:
http://www.brekeke-sip.com/bbs/viewtopic.php?t=7994
HA regression with Active Sessions status on 3.14.5.17
Moderator: Brekeke Support Team
-
dudley.aoi
- Posts: 31
- Joined: Wed Oct 17, 2018 2:21 pm
-
dudley.aoi
- Posts: 31
- Joined: Wed Oct 17, 2018 2:21 pm
True, it does not sync when the peer rejoins. However in testing it does show active sessions on the peer if there is another failover event forcing those sessions back to the original peer - at least in versions 3.13.0.0 and 3.12.1.5.
To clarify, my concern is in the case of:
a) long running sessions
b) primary fails to secondary, and then rejoins mirror
c) later secondary fails, sessions move back to primary, but with the same long running sessions still active
In this scenario, those long running sessions do properly stay active, but are no longer shown on the Active Sessions page. The issue is not that the sessions don't show back up on the primary when it rejoins - that's entirely fine. Honestly I prefer that as then we actually know which peer is handling that session at the time the page loads. No, the issue is no longer seeing the active session when it is still active, in the case of another fail over. I know that is a contrived scenario, but it is one we test for prior to upgrade implementations. In this scenario, if we needed to power cycle the secondary, we would lose visibility on those active sessions. In production, that would certainly not be ideal to just loose visibility on those sessions and only see new sessions.
To clarify, my concern is in the case of:
a) long running sessions
b) primary fails to secondary, and then rejoins mirror
c) later secondary fails, sessions move back to primary, but with the same long running sessions still active
In this scenario, those long running sessions do properly stay active, but are no longer shown on the Active Sessions page. The issue is not that the sessions don't show back up on the primary when it rejoins - that's entirely fine. Honestly I prefer that as then we actually know which peer is handling that session at the time the page loads. No, the issue is no longer seeing the active session when it is still active, in the case of another fail over. I know that is a contrived scenario, but it is one we test for prior to upgrade implementations. In this scenario, if we needed to power cycle the secondary, we would lose visibility on those active sessions. In production, that would certainly not be ideal to just loose visibility on those sessions and only see new sessions.