Hello @dmitry.s , how are you?
I think I’m facing an issue similar to the one with SWSS.
I have a yeti/sems node behind a NAT. Due to provider requirements, I need to send the public IP in the contact.
For this, I adjusted the public-address in signaling-interfaces.
This change made the invite send the contact with the public IP, however, when the provider sends a 200OK, the sems doesn’t respond to the signaling.
Do you have any tips on how to fix this?
LEFT: sems, RIGHT: provider
it is not possible to troubleshoot anything using just image. Could you provide:
Hello Dmitry, I apologize for the lack of clarity in my initial message.
On the same LAN as the Yeti, there’s an Asterisk system with a local IP of 10.X.X.21. It generates invites to the Yeti using this private IP to yeti (10.x.x.241).
When the Yeti receives the invite, it modifies the contact to use the public address and then forwards it to the service provider. This part works as expected.
However, I’m encountering a problem: the Yeti is also adjusting the contact for the internal connection between the Asterisk and itself (which operates over LAN). Consequently, the ACK from Asterisk, which should go to the Yeti’s local address, is mistakenly being sent to the Yeti’s public address (191.x.x.243). For reference, the public WAN address for my internal Asterisk is 201.X.X.160.
I’ve tried various configuration combinations, and the only one that came close was this:
sip-udp {
public-address = 191.X.X.243
force-contact-transport = off
force-via-address = on
use-raw-sockets = on
address = 10.X.X.241
port = 5060
}
This is expected behavior in your configuration,
Consequently, the ACK from Asterisk, which should go to the Yeti’s local address, is mistakenly being sent to the Yeti’s public address (191.x.x.243).
It actually shouldn’t. By setting public address on interface you instruct yeti to advertise this address as endpoint for SIP. That means you should use this interface only for NATed traffic.
