I’d like to run Asterisk behind NAT with a dynamic public IP address. Probably the easiest way is to edit external_media_address and external_signaling_address after each IP change. The problem is that I’d have to restart the daemon which could interrupt active internal calls.
Hence I tried to use siproxd as the outgoing SIP proxy. Fundamentally it worked fine, at least while testing with Linphone. Unfortunately, Asterisk uses the outgoing_proxy URI as the REGISTER URI, but siproxd cannot extract the real host for forwarding. Linphone sends its REGISTER query with the real host as the URI.
I thought about two Asterisk instances, one for internal calls and the other for outgoing purposes which I can restart regardlessly (in case of an IP change).
Assumed my provider does really not care about the Contact header, what could be the problem instead?
See the INVITE above.
My idea was that the proxy registers the public IP and the INVITE cannot be assigned by my provider’s server because of the different host in Contact header (127.0.0.1).
It’s because you are using a local proxy. The code finds the IP address that is being used to contact the target and uses that in the Contact so the contacted thing can reach back. I’m not familiar with siproxd but it should replace that value in the Contact header when going to the VoIP proxy, otherwise if they don’t do any NAT traversal then it would go to the wrong place.
I’ve double checked the RFC, and the proxy should not modify the Contact header. It should use Record-Route to ensure a return path.
Although, I suppose 403 could mean almost anything, normally a bad Contact header on an outgoing request doesn’t show up until the peer tries to re-INVITE, or close the call. (A bad Contact on a response tends to show up about 30 seconds after answer, when the ACK is timed out.
I think there has been the occasional request here for fine control of the Contact header because SIP implementations are, incorrectly, trying to read meaning into which the standards simply do not give it.
As 403 could mean what the ITSP wants it to mean, one really needs the ITSP to say why the call was rejected.
Also, I think the OP was speculating that the problem was related to sending s, rather than the incoming call extension, in the Contact header, but there is no requirement that these be the same.
The user portion of the Contact can be set using the contact_user option in an outbound registration.
As for your comment - this is both true and not true, it depends upon which interaction. In the case of a REGISTER a Record-Route doesn’t guarantee that subsequent requests will go through the proxy. Path was actually created for that purpose, but that requires remote support.
I think they are concerned about INVITE, rather than REGISTER. There are no symptoms on the REGISTER, but they are clutching at the disparity between the user on the REGISTER contact and that on the INVITE, and thinking that making the INVITE the same as the REGISTER might help.
@ast2301 Your problem is likely due to something siproxd is doing to the message or the fact a proxy is present and the provider not liking that. The INVITE you have provided is valid.
Assumed I have an internal call via Asterisk. Can I reload external_media_address and external_signaling_address without interrupting my call? Certainly Asterisk would have to re-register at the provider with the its new public IP.
If the “allow_reload” option is set on the transport then it can be reloaded. In the latest version if you also have the res_stun_monitor module configured and loaded it should also cause outbound registrations to get refreshed automatically. This wouldn’t impact any calls in progress.