Connecting GD3 to a CPU through Public IP Address

[wallacezammit]

Hi,

I have a situation where I have a crystal hardware rel 9.1 with CPU6 having internal IP address as 10.201.100.180.

Then I have to connect a shelf using a GD3 in another site where this site cannot see directly the IP@ 10.201.100.180 but can see a Public IP address (10.144.32.10) which is then routed to 10.201.100.180.

The problem is that when the GD3 is starting up it downloads the information from the CPU and obviously the IP addresses don't match because the GD doesn't know about the IP@ 10.201.100.180 and so it doesn't start up. There is lack of communication between the cpu and the gd3 because of the IP@s.

Is there a way to go around this?

Regards
Wallace

[vad]

May be your network not properly managed.
But in any case for GD side you can manage IP address/mask/gateway and declare CPU IP address 10.201.100.180.
On router manage NAT for destination (when GD send packets to 10.201.100.180 - NAT will chage this address to 10.144.32.10).

On CPU side you will use classical NAT 10.144.32.10 --> 10.201.100.180, on GD side you will use NAT for destination 10.201.100.180 --> 10.144.32.10 (the same management you will need for INTIPA).

[wallacezammit]

Yep I already told the network guys about this solution but I don't know why they are finding problems.

Anyways. So I would like to be 100% sure about this. If the GD has a cpu@ which is a public IP@ (10.144.32.10) and not the true IP@ of the CPU (10.201.100.180), does it still work? or it can never work? My point is that when the GD starts TFTP downloading from the CPU, the cpu will name itself as 10.201.100.180 which is a non recognisable IP@ for the GD. The GD knows the CPU with a different IP@ (10.144.32.10) and so the GD can never start.

Is my reasoning correct or am I going wrong somewhere?

[krzysioD]

As docs say: nat is NOT supported. Somewhere in UAUDP packet there is real IP that is should go to / from.
Use any kind of ip tunnel (and check if MTU is good) or, simply use public IP but pay very, very, very much attention to proper firewall.

[OXE_4400]

Its funny but 10.144.32.10 can't be public at all as far as I understand. All 10.x.x.x range is for private use only.

[wallacezammit]

That's the IP@s the IT guys gave me

Also now they are going to create a tunnel to have a direct connection of IPs.

Thanks guys!

[krzysioD]

Make that a beer, and say to guys "What max MTU you could give me without a fragmentation" and "kindly please crypt this tunnel with any simple encryption you could give".
As for MTU - check in MGR the max MTU, it does great for routers to pass RTP packets with MTU << then native MTU of IP tunnel, routers then don't have to fragment /defragment, and you have better audio quality (higher MOS).

[OXE_4400]

As docs say: nat is NOT supported. Somewhere in UAUDP packet there is real IP that is should go to / from.
Use any kind of ip tunnel (and check if MTU is good) or, simply use public IP but pay very, very, very much attention to proper firewall.

Not sure what exactly mean, but its written in new TC1591:

6.4 From I1.605.29 version
6.4.1 Send blank RTP packet for outgoing T38 calls
Problem of FAX call (T38) in case of NAT : when the fax call is sent, the NAT is waiting T38 frames to open the port on the NAT, if no frame are sent by the OXE (GD in fact) the NAT doesn't open the port, and the FAX call failed.
The solution is to send some T38 frames (empty frames for instance) to allow the NAT to open the port. This behavior is manageable with system option..
The new management parameter is in :
mgr>IP>D/H>Fax parameters, "NAT Support for T38” must be put to True (default value False)

[krzysioD]

LOL! after more than 5 years, ALU has almost usably implemented a T.38 ! I read this like that:
if you have a sip-to-fax gateway (from ALU compatible partner list) and set this to TRUE it has a chance to succeed in case of NAT
it was audiocodes 2 FXS (two Z/SLI) gateway i think.