[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.
- Problem with proxy incoming calls, and NAT,
Björn Tackmann <=