X-ast-orig-host – How Is This IP Taken ?
Hi list,
We have a strange behavior: a customer Snom300 behind a public FW has contact like
contact :
sip:user@x.y.39.147:2048;x-ast-orig-host=169.254.252.1:2048
The phone can place calls but not receive any. Also, qualify give unreachable which seems correct when looking the x-ast-orig-host IP. Problem is that the local IP of this phone is 192.168.1.75
Question: how asterisk sets this IP ? It looks for us like a FW issue as we have other customers with approaching local network organisation and which are not facing this problem.
Thanks for any hint.
—
Daniel
—
One thought on - X-ast-orig-host – How Is This IP Taken ?
–00000000000059f12605a7d0ddf1
Content-Type: text/plain; charset=”UTF-8″
x-ast-orig-host is a header we add to incoming requests when rewrite_contact is on AND the host we get the request from is different from the host in the contact URI. We do this so we can restore the original contact URI when we send responses. Here’s the scenario…
A client behind a firewall sends Asterisk a REGISTER request. The contact URI is probably going to be a non-routable ip address like 192.168.0.1 but the host the packet comes from will be the public ip address of the firewall. In order to properly route responses and subsequent requests, the “rewrite_contact” option can be used to force Asterisk to substitute the private ip address in the contact header with the public ip address we actually got the packet from. This way we send responses and new requests to the public ip address. This all works well except for 1 scenario… When a client sends a REGISTER request, they can use the IP address in the contact header of the response to match it to the request. If we’ve rewritten the contact header, they won’t be able to match it. So we save off the contact host into that x-ast-orig-host header and when we send responses back to the client, we still send it to the public ip address git we reset the contact host back to what was in the original request. We then strip all x-ast* headers before we actually send the packets.
Well, 169.254.x.x addresses are Automatic Assigned Ip Addresses assigned by the device itself when it can’t get a dhcp ip address. It’s highly unlikely that things are going to function normally if the device doesn’t have a real ip address.
See above. You should also check that the router the phone is connected to does NOT have SIP ALG turned on because that will mess with the SIP headers.