Want to use Original Source IP when phone registered behind CGNAT address

1. Brekeke Product Name and Version: Brekeke SIP Server Advanced Edition 3.17.2.1/583

2. Java version: 11.0.0.1

3. OS type and the version: Ubuntu 24.04 LTS

4. UA (phone), gateway or other hardware/software involved: Yealink T41S

5. Your problem:
In the Configuration page under 'Network' I have the External IP address pattern "^100.6[4-9]|^100.[7-9][0-9]|^100.1[0-1][0-9]|^100.12[0-7]" to handle CGNAT addressing within our network infrastructure which works fine.
A registered connection such as the following can be seen:
sip:01425000000@100.70.0.19:5060(100.70.0.19:5060)

However, in this scenario I have a CGNAT IP address from Starlink hidden behind a true public source IP address. The calls get sent to this non-routable CGNAT address where the call fails. I am looking to add something in place to deal with this.
This can be seen in the registration page under column heading 'Contact URI (Source IP Address)' for example:
sip:01425000000@100.106.190.130:5060(150.228.39.123:61490)

The IP address ‘100.106.190.130’ is the CGNAT address example from Starlink. Inside the brackets '150.228.39.123:61490' is the source IP and port that needs to be used to communicate with rather than the CGNAT IP address.

I tried using the dial plans to retrieve the source IP address with port and replace the ‘To’ value, but no luck.

The External IP address pattern is likely working against me here. Perhaps a condition where if the source IP address is not CGNAT then it should be used instead could help solve it.

Any suggestions? Anyone else had problems with Starlink connections or it be CGNAT related?

Try this kind of dialplan rule.

========================
[Matching Patterns]
$request = ^INVITE
$regdb.requester = (.+)

[Deploy Patterns]
$target = %1
$continue = true
========================

Hi James,

Thanks for the response on this.

I tested your rule with my setup and unfortunately it doesn't work as expected.

It skips my dialplan rule and moves on to the next rule.

Without '$regdb.requester = (.+)' in the Matching Patterns section, my dialplan kicks in, but when included, it moves on.

I noticed '$regdb.requester' is not mentioned in the documentation nor shown in the Variable drop-down menu list.

I can only see $regdb.attribute, $regdb.recordnum & $regdb.transport in the list and documentation.

Any further suggestions on this would be greatly appreciated.

Enable "Dial Plan" logging on the [Diagnostics] -> [Debug Logs] page and check what $regdb.requester returns.
It should be the remote IP address of the REGISTER request, such as 150.228.39.123:61490.

Hi James,

I get the following show in the debug log for '$regdb.requester':

Pattern: $regdb.requester = (.+)
Input: $regdb.requester = null
Result: false

All other patterns in the same dial rule result in 'true'.

Does this look as expected? Anything else I can do here?

Thanks.

If the called party is registered on the SIP server, $regdb.requester should return the remote IP address of the REGISTER request.
If it returns null, it appears that the called party is not registered.
Check [Registered Clients] to confirm whether the called user is registered.

Hi James,

Thank you for the advice here.

Adding '$regdb.requester("<username>") = (.+)' into the 'Matching Patterns' section got me the public source IP and port I was after.

However, with this in place, SIP worked but audio was only one way as it was still trying to send RTP data to the CGNAT address.

I then came across '&net.rtp.follow.remoteaddr=true' deploy pattern which resolved the one-way audio.

I had to add this to my inbound and outbound dial rules for this scenario.

Turns out in the end I didn't need '$regdb.requester' set in the dial plan, as long as I have STUN enabled on the SIP device which set the public source IP in the Contact URI.

Anyway, I’m glad to hear that you resolved the issue.