Can you point me to documentation on what "net.bind.use" does?

Closest I can find is net.bind.interface. Similar, but different: https://docs.brekeke.com/sip/bind-breke ... ip-address

Would I need to set net.bind.interface explicitly before using net.bind.use=true?

The "fix"/workaround for this is apparently to configure SIP trunks for the Brekeke node IPs of the primary and secondary on the far end equipment.

There does not appear to be any way to force Brekeke to only use the cluster IP.

Unfortunately due to constraints imposed by our networking team based on how we observed Brekeke functioning, yes, BREKEKE_CLUSTER_IP and BREKEKE_PRIMARY_IP are in the same network segment in this example. I believe years ago (2018) we tried initially setting it up as per the documentation example ...

1. Brekeke Product Name and Version: Brekeke SIP Server 3.14.7.4/563.3 2. Java version: OpenJDK 64-Bit Server 11.0.20 3. OS type and the version: RHEL 8.8 4. UA (phone), gateway or other hardware/software involved: Genesys SIP server 8.1.104.42 on Windows 2019 5. Your problem: When a failover rule ...

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 ...

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 ...

That sounds great, but by default all those categories under "SIP Server log settings" are unchecked. Which means none of that is enabled by default . So all I find in those sv.*.log files are general information like startup time, Java memory information, session and packet counts. I'll have to do ...

Do you want to let the Brekeke SIP Server handle 3xx redirection responses without forwarding them back to the call originator? Yes, that is exactly what I want to happen IF we actually get a 3xx redirect response. What I do not want is for failover to happen if we get literally any other response ...

Today an opportunity presented to be able to test this, and yes setting &failover.pattern.response = ^$ DOES in fact work for this! I received a bit more information, and the destination is actually a pair of Avaya PBXes sitting in front of the Genesys (not sure if the forum will allow me to update ...

1. Brekeke Product Name and Version: 3.13.0.0/552 2. Java version:11.0.16 3. OS type and the version: RHEL7 4. UA (phone), gateway or other hardware/software involved: Avaya & Genesys SIP Server 5. Your problem: Using the failover module in Advanced Server, we want to fail over if and only if the ...

1. Brekeke Product Name and Version: SIP Server 3.13.0.0/552 (started with version 3.12.2.2) 2. Java version: OpenJDK 17.0.2 3. OS type and the version: CentOS 7.9.2009 4. UA (phone), gateway or other hardware/software involved: N/A 5. Your problem: Using OpenJDK 17 results in an error message of ...

This appears to be fixed in 3.13.0.0 (however it still requires going back to Java 11).

It appears there might be a log buffering regression there too, as even with a graceful reboot sometimes the call might not appear in the logs of the designated primary. That's really odd.

We'll be staying on 3.12.1.5 until this bug gets fixed.

Clarification: Switching the roles manually after the event has no effect on the situation whatsoever: if the call originated with both primary and secondary up, and the designated primary is rebooted, then when the designated primary comes back up, there is a switch role performed (on either the ...

1. Brekeke Product Name and Version: Brekeke SIP Proxy Server 3.12.2.2 2. Java version: 11 (required for 3.12.2.2, whereas Java 17 worked perfectly with 3.12.1.5) 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 ...

Harold, How does net.sip.tcp.connection.put.followable=false effect session behavior if the TCP session was initiated by far end (not Brekeke SIP server)? For example, Avaya PBX sends SIP options packet to check if Brekeke peer is up. Let us call this TCP session A (Avaya:ephemeral_port -> Brekeke ...

Update: As of version 3.9.1 or above (we are currently running 3.9.2.7/517), dial plan sync does in fact work! :D Dial plan sync is enabled under System Menu -> Redundancy -> Auto Sync tab, by ensuring that "Dial Plan" is set to Yes on both primary and secondary. I am very happy about this addition ...

In that case, net.sip.transport.share.connection=false is exactly what we want here!

What does "net.sip.transport.share.connection=false" do, specifically?

Upon further testing, net.sip.tcp.reuse = false was causing issues ( all calls from Avaya fail, with error 404 from the Avaya), but net.sip.tcp.connection.put.followable = false does not appear to cause the same issues. Our Avaya team found Avaya document SOLN2844625 about this specific issue. Of ...

I tried net.sip.loglevel.file = 16 but that only logs the response code , not the response phrase . After testing, it seems the only way I can reliably capture the response phrase in the logs for non-error responses is by turning on debug logging with net.sip.loglevel.file = 64 . For errors, such as ...

Perhaps what I am really looking for is a detailed list of what the logging levels provide. For example, if I set net.sip.loglevel.file = 26 to include Status level, would that include the reason phrase in the log? What specifically is logged at the status and detail levels, different than full ...

Yes, but that only shows the SIP response code, not the actual reason phrase. What I really want is a way to capture the reason phrase that the Avaya is sending, without having to resort to debug logging or packet captures. As an example, let us assume the Avaya responds to an INVITE with a SIP ...

1. Brekeke Product Name and Version: Brekeke SIP Server 3.8.6.4/501 2. Java version: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 10.0.1 3. OS type and the version: CentOS Linux release 7.5.1804 (Core) kernel 3.10.0-862.14.4.el7.x86_64 4. UA (phone), gateway or other hardware/software ...

Unfortunately, those net.sip advanced settings actually exacerbated the issue. What resulted was a storm of TCP RSTs from the Brekeke to the Avaya and all the calls failing. :cry: I then removed both of those directives from the Brekeke, because intermittent failure is better than total failure (at ...