VoIP: Symmetric Response Routing
This issue was reported to me by a reader of this Web page. Thank you!
Port open!
You have a Firewall, usually in your Internet-Access Device like your router at home. Or, if you use the Internet access of your mobile network, your mobile operator runs a Firewall for you. When a call comes in, your SIP service sends you a INVITE message. Consequently, a port must be open in the Firewall, so this messages arrives. You open that port (with your SIP REGISTER message). Then, either your local SIP User Agent – your phone – or your remote service provider make sure it does not get closed (in UDP with a double CRLF-Refresh every 30 seconds, or a TCP-Keep-Alive message every five minutes).
Port correct?
Your provider checks whether a TCP connection is establised already and re-uses that.
SIP header Contact
Unfortuantely, some services do not re-use the connection. Instead, they rely on the port in the SIP header Contact. Some try to be clever: They rely on the port (only) if its IP address is public. That happens easily when you use IPv6 for example. Consequently, for such services, the SIP User agent must present the correct port.
Affected TCP/TLS clients
The following SIP User Agents (from my collection) are affected for sure because they allow IPv6:
- Auerswald
uses an ephemeral port but declares another ephemeral port
- AVM FRITZ!Box
uses an ephemeral port but declares 5061 fixed since FRITZ!OS 07.24
- Digium Asterisk/chan_pjsip
uses an ephemeral port but declares the port of bind (default 5061)
- Digium Asterisk/chan_sip
uses an ephemeral port but declares the port of tlsbindaddr (default 5061)
- Google Android
The internal client within the app Phone which is not available in all distributions; tested Android 11 Phone 53.0.
uses an ephemeral port but declares another ephemeral port
requests rPort in TCP but does not update headers; nevertheless might trigger a different logic at service, see ASTERISK-26438
- Panasonic
uses an ephemeral port on default but declares Web → VoIP → SIP → Line 1 → Local SIP Port (default: 5060)
Mitigation A: Web → VoIP → SIP → Enable Rport (RFC 3581): Yes; requests rPort in TCP but does not update headers
nevertheless might trigger a different logic at service, see ASTERISK-26438; if not, go for
Mitigation B: Web → VoIP → SIP → TLS Port random: No and optionally: Web → VoIP → SIP → Line 1 → Local SIP Port: any value
- SignalWire FreeSWITCH
uses an ephemeral port but declares tls-sip-port
default of vanilla configuration: external_tls_port = 5081
default if unspecified: SOFIA_DEFAULT_TLS_PORT = 5061
default if value is "auto": not the used but another ephemeral port
IPv4-only: requests rPort in TCP but does not update headers; nevertheless might trigger a different logic at service, see ASTERISK-26438
Mitigation: open the tls-sip-port of your external gateway(s) in your Firewall
Service providers, go get one of those (without rPort; for example the Panasonic) and double check your configuration!
Affected TCP/TLS servers
Some implementations try to fix wrong IP ports in the SIP header Contact on default. Does that logic consider a public IP address with a wrong port? By the way, instead of fixing wrong ports, those implementations should have used the existing TCP connection before even looking at the header Contact.