flexisip-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with proxy incoming calls, and NAT


From: Björn Tackmann
Subject: Problem with proxy incoming calls, and NAT
Date: Fri, 1 May 2020 22:58:29 +0200

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]