Solved Dedicated NIC for IP auth SIP RTP from wrong interface

[hood]

Hi All,

I've just built up a new Debian 3CX system with 2 NICs setup as recommended.
Main NIC - Network / Phones and Internet 192.168.xx.1 (gw 192.168.xx.254)
2nd NIC - Dedicated SIP only 10.xx.yy.30 (static route to SIP server 3.4.5.6 via 10.xx.yy.29)

The 2nd NIC is plugged directly into the NTU on site that is a dedicated circuit for the SIP service. I have a static route on the Debian instance to route traffic to the SIP service via the dedicated NIC and gatway IP via the NTU. This is working perfectly.

I have configured a generic SIP trunk in 3CX, using IP authentication, and using the provided SIP server IP (the one that I have the static route working successfully for). SIP appears to be working fine, I can make and receive phone calls. Well when I say make and receive, the setup and tear down is working, but no RTP voice traffic.

Using the packet capture built into 3CX on eth1 I can see my SIP traffic behaving, but the RTP traffic appears to be being sent to the SIP service (3.4.5.6) FROM my internal main NIC ip address, 192.168.xx.1 and NOT the 2nd NIC IP address dedicated for the SIP trunk 10.xx.yy.30.

I believe this traffic isn't being routed correctly, and the SIP server will not know how to route it back because it is coming from the wrong IP.

Any ideas on how I can force the trunk to use my 2nd NIC ip address for the RTP traffic?

Thanks in advance

 

[Saqqara]

Check out, may help -
https://www.3cx.com/community/threads/how-do-i-add-static-routes-to-3cx-on-debian.53580/#post-219597

 

[hood]

Hi Saqqara,

I have read that post many times, and I have my routing working correctly.

I'm one step closer now with one way audio

I was able to resolve this issue by changing the "Select which IP to use in 'Contact' (SIP) and 'Connection'(SDP) Fields under the options tab of the SIP trunk. I changed to "Use this IP address" and entered my IP address on the eth1 interface.

 

[YiannisH_3CX]

Hello @hood

Has the issue been resolved or are you still using facing one way audio?

 

[hood]

Fixed now thanks YiannisH.

It seem the one way audio was a flaw in my testing, and seems to be an issue with using the 3cx phone app as my extension. When I configured a remote extension to test instead we have two way audio.

Thanks for following this up.

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for updating the thread.