If you updated someone's account directly at the database, remove the cached record under the same username with the command below. authcache remove <username> It lets the SIP Server read the database and cache it again. If you want to execute the command remotely, refer the page below. https://docs ...

Which 3rd party DB system are you using ?
How many records do you have in the table?

If you update the DB directly without managing through the GUI, the BSS doesn't know the content of the DB.

To avoid this, let you use the REST API for managing the database.
https://docs.brekeke.com/sip/bss-rest-api
https://docs.brekeke.com/sip/brekeke-si ... ir-methods

The Alias Database or the Phone book Database can be used for this purpose.
I recommend that you host The Alias Database with a 3rd party database system to gain a performance increase.

Set the line below in [Configuration]-[Advanced] page.

cdr.file.datetime-format = yyyy/MM/dd-HHmmss


But you need to make a directory, yyyy/MM such as 2024/08 manually.
You can check the path at [CDR]->[Status] page.

Try CDR

https://docs.brekeke.com/sip/call-detai ... r-settings
https://docs.brekeke.com/sip/variables-for-cdr

There are %{callidin} and %{callidout}.

The maximum value of Delay is 2147483647 (ms).

Use "Delay" plugin in Deploy Pattern.

Syntax:
$session = Delay [millisecond]

For example, if you want to add 5 seconds delay.
$session = Delay 5000

Glad to know it.

If 3CX to 3CX call still makes 2 SIP sessions over the Brekeke SIP Server, it means two RTP streams are made because each route has $rtp=true.

If you tune DialPlan rules to use a single SIP session like 3CX-to-upstream provider, you can save SIP server and router's resources.

> For a call between the two 3CX servers, whether the calls have audio or not, there are two entries in the Active Sessions list - one for the outbound portion of the call and one for the inbound portion of the call. For 3CX to 3CX case, it should be a single SIP session to avoid an issue if a ...

It seems there are configuration issues.
Does the BSS have a local (private) IP address?
Is the BSS located behind a NAT?

If you reproduce the issue, is it shown as a single SIP session in the [Active Sessions] page? or two sessions?

It seems the log setting is not applied yet.
Did you push [Update] button after you enabled "SIP Session" log category in [Debug Logs] page?
Once you applied the log setting, make a test call from one 3CX to another 3CX to reproduce the issue.

Please find sv.xxxx.log such as sv.240321.log not session.xxxx.log.
The session.xxx.log is kind of CDR and sv.xxxx.log is a detailed log which can include SIP packets.

You need to reproduce the issue after "SIP Session" log category is enabled.

You can find a session in the log with timestamp, From-URI and To-URI.
Check "rulename" to see it is expected rule names, and
"mode:RTPrelay" to see it is on or off.

Is the upstream service provider involved with this no audio issue? This is because you have "$addr=upstream-service-provider-ip" in the rule "3CX-A: Inbound". For having a detailed log, set "SIP Session" in [Diagnostics]>[Debug Logs] page and reproduce the issue. Then find the sv.xxxx.log (eg: sv ...

If possible can you paste DialPlan rules which caused the no-audio call?
They will be two rules. 3CX-B outbound and 3CX-A inbound.

You can analyze RTP packets with Wireshark. First, capture packets when you make a call from one 3CX to another 3CX, and say something even if there is no audio. Second, at Wireshark, go to [Telephony]>[RTP]>[RTP Streams]. If there is no RTP stream, $rtp=true is not applied. If there are RTP streams ...

Does the BSS have more than one public IP address?

If you capture SIP packets when you make a call from one 3CX to another 3CX though the SIP Server, which IP address does SDP point?
Is it the BSS's public IP address or caller 3CX's public IP address?

How about this?
=============
[Matching Patterns]
$request = ^INVITE
$registered = false
To = sip:(8888)@
$getdisplayname(From) = GGGxx(.+)

[Deploy Patterns]
To = sip:%1@10.10.10.10
From/displayname = GGG%2
=============

If it is a dialed number, you don't have to use a displayname.
==============
[Matching Patterns]
$request = ^INVITE
$addr = ^192\.168\.
To = sip:50\*(.+)@

[Deploy Patterns]
To = sip:150\*%1@10.10.10.10
==============

Can you try the DialPlan rule like this?
========================
[Matching Patterns]
$request = ^INVITE
$registered = false
To = sip:(8888)@
$getdisplayname(From) = GGGxx

[Deploy Patterns]
To = sip:%1@10.10.10.10
From/displayname = GGG
========================

John, you are right.

In DialPlan method parameter, there is no data types such as Boolean and Integer. So the true should be written as "true".

If you are familiar with Java, you can develop your own DialPlan method.
https://docs.brekeke.com/sip/bss-dial-p ... pers-guide

Use $not https://docs.brekeke.com/sip/not [Matching Patterns] $request = ^INVITE $registered("UserName") = true $addr = ^PBX_IP-Address$ To = sip:(.+)@ $not($alias.lookup("%1")) = (.+) [Deploy Patterns] $rtp = %2 You can also use $if [Matching Patterns] $request = ^INVITE $registered("UserName ...

Are these 3 SIP entities on the same local network?
Are they behind a NAT?
Can both 3CX servers send ping packet each other directly?