Quote:
Originally Posted by 910198
For the ACK to arrive it is necessary to create some mappings on the firewall. This is simply impossible on public networks.
|
This is not true. In your case you are expecting the ACK to come back on port 5060 because your device is instructing the other end point to do so via the CONTACT information it is passing in the OK message. This is why you are forced to modify the firewall rules.
Normally when a device is sitting behind a firewall, and using something like STUN, the CONTACT header will contain a front facing port (that the firewall knows to forward to the internal IP) as determined by the STUN protocol. Depending on whether you are sitting behind a full cone NAT, restricted cone NAT, port restricted cone NAT or symmetric NAT router this port can vary (something like 53451 for example).
If you choose not to use STUN or open up your firewall, the other option is to register your device with a server (like Voxalot) that has server based NAT handling. In this case the proxy will do the NAT handling on your behalf and the SIP messaging will be proxied.
As a simple test,
turn off NAT handling (this is extremely important) on your device and register it with Voxalot. Using one of the access numbers, dial *010xxxxxx where xxxxxx is your Voxalot number.
In this scenario, you will see the ACK message come from the Voxalot proxy you are registered against. Once again, this is due to the fact that Voxalot is performing the NAT handling on your behalf
So just to re-iterate, if you want to properly receive the ACK message from the other end point, and you are behind a firewall, you must either:
1. Use a protocol like STUN to perform client side NAT handling (
Note: STUN is broken in SJPhone and needs to be disabled. Make sure the "Use discovered addresses in SIP" is unchecked. I suspect this is half your problem)
2. Open up your firewall ports and forward to your device
3. Register your device with a proxy that has built-in NAT handling capabilities.
.