| Dear all,
I solved my problem below, and I thought I’d let you know, as the solution was somehow unexpected. The server apparently did not send the ACK at all. It apparently choked on the Path header that was introduced by flexisip relaying the “200 Ok” accepting the call. So the solution was to set, in flexisip.conf:
==== [module::Forward]
add-path: false
That way, the ACK is properly relayed back through flexisip, as expected.
The more direct answer to my below question, however, is that the ContactRouteInserter has an undocumented parameter, masquerade-contacts-for-invites=true, which does exactly what I asked for. That helped me debug and find the issue with the Path header. After fixing the Path header, the method without masquerading also worked as expected.
Best regards, Björn
Begin forwarded message:
Subject: Problem with proxy incoming calls, and NAT
Date: May 1, 2020 at 10:58:29 PM GMT+2
Dear all,
I am using flexisip as a proxy and I am experiencing an issue with inbound calls under some conditions. The setup is as follows:
end device <== connection with NAT ==> flexisip <== plain IP ==> SIP server
The end device REGISTERs properly, and flexisip also adapts the Contact header, so incoming INVITEs do go through flexisip, and to the end device. In the “200 OK” sent by the end device following the INVITE, however, flexisip does NOT adapt the Contact header, so that one bears the public IP of the NAT gateway. The ACK sent by the server never arrives at the end device (nor at the flexisip server).
The result is that the end device, not having received an ACK, times out and cancels the call. Before the cancellation, the call actually works nicely, as all SDP is sent through flexisip via MediaRelay. Only the ACK isn’t.
Although I could not observe all network communication, my interpretation of what happens is as follows: The server attempts to send the ACK directly to the end device (i.e., to the public IP of the NAT as stated in the Contact header). The NAT gateway drops the ACK, as it only observed a connection with flexisip. My interpretation of the RFC is that the server sending the ACK directly to the end device is perfectly legal according to SIP — it could be routed via the proxy as well, but that is not mandated.^1
Is it possible to have flexisip also modify the Contact header in the “200 OK”, and relay the ACK? This would be consistent with the handling of the INVITE, and I think it should solve the issue. I could not find anything about this in the documentation.
Or: are there other possible solutions without modifying the NAT or going through a VPN (which should work, but have other disadvantages), which I may be missing?
Thanks and best,
Björn
^1 I could not directly test this, but I did quite a bit of testing on both the SIP server and the NAT, and all behavior I observed is consistent with this.
|