I have a system asterisk (16.8) for which I would like to create a backup route if one of the nodes through which the voice passes is congested.
My scenario is as follows: clients (behind nat) register on my asterisk machine and once registered they are successfully called from my asterisk machine.
Now suppose the public client address is 69.145.123.22 and my asterisk machine’s public address is 46.28.66.39 and a route node is malfunctioning, the audio sounds noisy.
I created a vps (46.25.34.22) vps off the path and forwarded all incoming traffic to the asterisk machine this way:
echo “1” > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 1:21 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 23:65389 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
iptables -t nat -A PREROUTING -i ens3 -p udp -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
iptables -t nat -A PREROUTING -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE
I set the client so that its sip server on which it must register is obviously 46.25.34.22 and the registration occurs correctly
when the client is called by asterisk , it nswers via 46.25.34.22 but the audio is always on the old path.
How can I make audio pass through 46.25.34.22?
This sounds like double NAT; both Asterisk and the external endpoint are behind different NATs.
I think you need to provide details of your chan_pjsip configuration, but I think there is something wrong with your external media address. Another possibility is that
Note that Asterisk 16 is no longer supported, and I have assumed chan_pjsip, as chan_sip is, effectively unsupported.
Also note that you have used clients when you man registrants. In the scenario you describe, in the last paragraph, Asterisk is the client user agent.
A diagram would be very useful, as I find the description confusing.
Should the man on the right have a different address? I thought you said they were behind NAT.
In any case, in the first case, Asterisk appears to be directly on the internet, but in the second, it is behind NAT, so in the second it needs signalling and media addresses set and local networks should be set.
To ensure that the audio traffic also passes through your backup route (VPS at 46.25.34.22), you need to perform NAT manipulation on the RTP (Real-time Transport Protocol) traffic in addition to the SIP signaling.
Forward RTP Traffic: You need to forward UDP traffic on the RTP ports (usually within the range 10000-20000) to your Asterisk server.
Modify RTP Packets: When RTP packets leave your Asterisk server, they should be rewritten to appear as if they’re coming from the VPS (46.25.34.22).
# Enable IP forwarding
echo “1” > /proc/sys/net/ipv4/ip_forward
# Forward SIP Signaling
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 1:21 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 23:65389 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 5060 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
# Forward RTP Traffic
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 10000:20000 -m conntrack --ctstate NEW -j DNAT --to 46.28.66.39
# Allow established/related connections
iptables -t nat -A PREROUTING -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Source NAT for outgoing traffic
iptables -A POSTROUTING -t nat -j MASQUERADE
Ensure that the RTP ports range (10000:20000) covers the range used by your Asterisk server. Adjust this range if necessary.
This is only useful if the other party is sending packets to the NAT device. There might be an issue here (because of double NAT and reliance on symmetric media), but it won’t manifest itself until the the remote side starts sending to the fallback address.
In what way do the iptables rules you quote not do that?
Actually, I can’t see how you could have got the SIP and RTP, from Asterisk to go through different routes, unless you have declared your device in the middle as a proxy, or you have port dependent routing rules on the Asterisk machine.
