Because Java 16 is not LTS (Long-Term-Support) version, Java 11 is recommended.

FYI:
https://www.oracle.com/java/technologie ... admap.html

Usually, java is symbolic linked from /usr/bin/java so replace it with new Java location.

Or set the new Java path to the environment variable "JAVA_HOME".

Have you restarted the PBX after you disabled Authentication settings?

Can you make a registration successfully without an Authentication error?

No. This is because BSS has a RTP proxy feature internally.

Are these destination IP addresses located in same network segment?

As a SIP proxy server, Brekeke SIP Server doesn't generate REGISTER by itself.

Does Telecenter U support SIP-REGISTER? and it supports authentication? If so the SIP Server can relay it to the Cloud Hosted PBX.
Otherwise, Brekeke PBX will be a solution because it has the feature.

What kind of SIP client is the customer using? Does your Cisco Router Firewall close an outgoing TCP connection just after local entity sends a message over TCP? (If so, you can not access to a web from behind the router.) According to the RFC3261 If the "sent-protocol" is a reliable transport ...

It seems this is an issue at the Rauland side. Let you check the RGS's log to see why it redials a call.

Are there any Route header in INIVTE sent from the same UAC? If yes, how many Route headers are they? and are they pointing the SIP Server's IP address? > Do you think, it is causing the issue? I think one Route header for pointing the SIP Server's IP address is no problem. But two.. it might cause ...

Try the Heartbeat function which sends OPTIONS periodically. https://docs.brekeke.com/sip/monitoring-sip-devices-with-heartbeat And specify a management command "ruleswitch" as Heartbeat's Action to disable the DialPlan rule which points outgoing SIP server. Like this: Type : Management Command ...

> UAC sent the ACK with ROUTE: <IP_ADDRESS>, that IP address belongs to BSS. Then BSS should take the ACK and send it to UAS, inst it? It is true. Do you know why the UAC puts the same Route header twice? It should be one. Route: <sip:192.168.10.10:5060;lr> Route: <sip:192.168.10.10:5060;lr>

It seems ACK was routed based on Route: header what UAC announced.

Add the line below at Deploy Patterns.

Let you check the status of the session at the SIP Server. It shows whether the SIP Server accepted ACK or not.

Does the same issue happen even if you use another SIP client as UAC?

Check the [Status] field at [Active Session] page.
Is it "Ringing" , "Accepted" or "Talking"?

It can be done by custom session plugin or CDR plugin.

> but we cannot do forward registration using DNS names.

Let the SIP server knows the DNS name.

Add the same DNS name in SIP Server's [Configuration]->[System] page -> [Interface address 1 ], and restart the SIP Server.

OnDO SIP Server 1.3.1.4 was released 14 years ago... Why you are still using such a very old version. According to the version history, TCP handing was added in version 2.2.0.7. https://docs.brekeke.com/sip/version-history-3 Let you upgrade your version 1.3 to the latest one. It is 3.9.1.3. It ...

Which SIP phone client are you using?
Does it send REGISTER over UDP? or TCP? or TLS?


> It is possible to keep register session before it expire.

What does "register session" mean? registration record?

Try like this.. It puts a packet back to DialPlan again. Rule-1: [Matching Patterns] $request = ^INVITE $localhost = ^true To = sip:spiral-(.+)@ [Deploy Patterns] To = <sip:%1@192.168.1.26:5060;cd40rs=R2> Rule-2: [Matching Patterns] $request = ^INVITE [Deploy Patterns] To = sip:111@ $session ...

It is not easy but possible. FYI: https://en.wikipedia.org/wiki/Regular_expression
A provisional Responses such as 180 is always passed.

Set them at DeployPatterns.

BSS will not pick 6th interface because it is a private IP address. For assigning 5th interface for RTP, use net.rtp.bindsrc and net.rtp.binddst variables at [Configuration]->[Advanced] page. For example, 5.1.1.1 is 5th interface's IP address. net.rtp.binddst = 5.1.1.1 net.rtp.bindsrc = 5.1.1.1

Do you have a DialPlan rule at the Primary server for routing this call?
If so, put the same DialPlan rule at the Secondary too.

Assigning a SID (Session ID) is different at each SIP Server. Also, depends on how call was ended (rejected or canceled), the Secondary Server keeps status of such ended sessions for a while even if the Primary Server doesn't show them at the Session List (technically Primary Server keep such status ...

> Should the sessions on the primary be found in the active sessions list of the secondary, Yes. > and vice-versa then? No. Because the Secondary doesn't mirror packets to the Primary. > would you expect to find a session with the same source and destination on the active sessions list on the ...