Can't call an remote extension via BRIDGE - Remote local ip address sent in REGISTER process

[rdias9]

I've created a BRIDGE in my 3CX Server to my client's PBX registers into it, so I can forward calls to its internal extensions.
I can't do that because when 3CX sends an invite, it sends to the internal IP of my client's PBX
I've noticed that during the REGISTER sip process, my client's PBX is sending its internal IP (I've copied the record below).
I wish that during this registration process, my 3CX server replaces the client's internal IP (sent in SIP PACKAGE)... by its PUBLIC IP (sent in UDP package).
Usually, this is made substituting the Contact SIP Field...
How can this be done in 3CX?


Environment
3CX PRO Server v16.0.1078
Hosted on AWS
My client doesn't have static IP
PBX: UTECH


*** REGISTER SIP PACKAGE received from my client's PBX ***
12/20/2020 5:50:43 PM - Updating device Dev(936364404):[sip:[email protected]:5060;ob / 10000] by message: DevUpd Recv Req REGISTER from 192.168.1.117:5060 tid=Pj5c11a7f560244f60bb11df2683804107 Call-ID=03aaf2ca9df84194a4efebdcb0b3e771:
REGISTER sip:doormai-tst.my3cx.com.br SIP/2.0
Via: SIP/2.0/UDP 192.168.1.117:5060;rport=5060;branch=z9hG4bKPj5c11a7f560244f60bb11df2683804107
Max-Forwards: 70
Contact: <sip:[email protected]:5060;ob>
To: <sip:[email protected]3cx.com.br>
From: <sip:[email protected]3cx.com.br>;tag=b0f1814a8afe43c694f230dc3dd63ae8
Call-ID: 03aaf2ca9df84194a4efebdcb0b3e771
CSeq: 34212 REGISTER
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Proxy-Authorization: Digest username="10000",realm="3CXPhoneSystem",nonce="414d53595fdfb92323:60cf1cefbf46765b1d45f322f54d0890",uri="sip:doormai-tst.my3cx.com.br",response="cb416ae57e791ab7e444fcd3902cd981",algorithm=MD5
User-Agent: UTECH/1.0
Content-Length: 0

 

[leejor]

Is the other PBX setup to register as a trunk, to 3CX? If it is, and would normally be registering to a provider, I don't fully understand why it would send it's internal IP.as hat would be unusable.

 

[JohnS_3CX]

> I've noticed that during the REGISTER sip process, my client's PBX is sending its internal IP

That will be a problem. Are you using our way of bridging to 3CX systems? If not ( I see a UTECH user agent ) then there is not guarantee this will work.

https://www.3cx.com/docs/manual/connecting-pbx-bridges/

 

[rdias9]

Is the other PBX setup to register as a trunk, to 3CX? If it is, and would normally be registering to a provider, I don't fully understand why it would send it's internal IP.as hat would be unusable.

Hi leejor, thanks for your reply!
Yes, it is registering using trunk...The software has a parameter to fill in the external IP, but in this case my client has a dynamic IP... so this field is unusable.
The manufacturer asked if 3CX has an option to replace the internal IP sent into SIP package by the external IP received in Network package....

 

[rdias9]

> I've noticed that during the REGISTER sip process, my client's PBX is sending its internal IP

That will be a problem. Are you using our way of bridging to 3CX systems? If not ( I see a UTECH user agent ) then there is not guarantee this will work.

https://www.3cx.com/docs/manual/connecting-pbx-bridges/

Thanks John!

Yes, I'm using brdge to connect both PBX... but the other one is registering as a SIP TRUNK...
Is there other way to connectthe other PBX to 3CX ?

Could 3CX SBC solve this problem ?
The idea is installing it on my client's local network... configuring a bridge tunnel with 3CX server...
And then UTECH PBX will register to SBC in local network...

 

[JohnS_3CX]

The issue here is that the other side is sending its local IP which as I understand will not be reachable to 3CX.

You will have to make sure the other PBX can use it's public IP in the contact field, and also in the SDP connection information.

The SBC can do this but it was designed and tested to work with supported 3CX phones, so it is unknown whether it can work for your intention.

 

[leejor]

The software has a parameter to fill in the external IP, but in this case my client has a dynamic IP... so this field is unusable.

It would seem that the PBX is designed to be used with a static IP, so unless there is a STUN option, somewhere, or the ability to use a URL in the IP field (If you a have DDNS service), you may be out of luck. Does that PBX have SIP trunks to a provider, that require registration?

Have you actually checked to see how often the dynamic IP changes? I have found that, depending on the provider, it can remain the same for many months.

 

[rdias9]

It would seem that the PBX is designed to be used with a static IP, so unless there is a STUN option, somewhere, or the ability to use a URL in the IP field (If you a have DDNS service), you may be out of luck. Does that PBX have SIP trunks to a provider, that require registration?

You are assumptions are correct leejor... About the provider what I know is that he has a VPN server, and the remote branches connect to him using this VPN, to register.

Have you actually checked to see how often the dynamic IP changes? I have found that, depending on the provider, it can remain the same for many months.

In our region this can change more often, usually once a week.

I'm testing the SBC solution in his local network, and until now it's working. Do you see any problem that I may have with this approach ?
Thanks again!

 

[leejor]

If you mean, installing an SBC at his location for the installation of extensions, then no there should not be, as the SBC will register to the 3CX PBX using the public IP at it's location.

 

[Fábio Ernando]

If the pbx behind a NAT, you must enable the NAT Traversal function so that it sends the WAN IP in the contact parameter on SIP header. So 3cx will start responding at the correct IP.
As your customer doesn't have a static public IP, it may be necessary for the SIP ALG enabed on the router in front of the network (it will be necessary to check the compatibility of the resource with the pbx manufacturer), however on the network where 3cx is installed, the SIP ALG function must always be disabled.

 

[Fábio Ernando]

Nat Traversal must be enabled on the pbx.

 

[rdias9]

If you mean, installing an SBC at his location for the installation of extensions, then no there should not be, as the SBC will register to the 3CX PBX using the public IP at it's location.

Exactly, thanks for the tips!

 

[rdias9]

If the pbx behind a NAT, you must enable the NAT Traversal function so that it sends the WAN IP in the contact parameter on SIP header. So 3cx will start responding at the correct IP.
As your customer doesn't have a static public IP, it may be necessary for the SIP ALG enabed on the router in front of the network (it will be necessary to check the compatibility of the resource with the pbx manufacturer), however on the network where 3cx is installed, the SIP ALG function must always be disabled.

Hi Fabio, thanks for the tip!
This NAT traversal function is a parameter of UTECH PBX or the router ? It's a microtik by the way...

 

[Fábio Ernando]

Hi Fabio, thanks for the tip!
This NAT traversal function is a parameter of UTECH PBX or the router ? It's a microtik by the way...

Must be a function of Utech pbx.