I have just recently switched to using an IP authentication trunk with Vitelity, who has different IP addresses for in and outbound servers.
My server is behind a NAT firewall.
When I make an outbound call and the other party hangs up, the final BYE message that the Vitelity server is sending to me is sent to the wrong UDP destination port and my firewall doesn’t forward it because of that.
It sends it to port 5060, but it should send it to the source port that the firewall has initiated traffic from for that UDP session and has received all other SIP messages to (trying, ringing, 200 OK), except for the BYE.
Anybody seen this behaviour?
In below capture I am obfuscating my public IP with 123.123.123.123:
I assume that this is a capture taken on the WAN interface of a hardware NAT / firewall device.
With IP authentication, Asterisk needs to simulate being on a public IP. This won’t work if your firewall is translating the source port number. The Contact header in the original INVITE sent by Asterisk will have e.g. Contact: <sip:[email protected]:5060>
and that’s where Vitelity will send BYE (and re-invites).
So you need to ensure that the NAT router does not translate the source port number. Some firewalls always select a ‘random’ port by default; try turning that off.
Or, the port number may be translated because another device on the LAN is sending packets from its port 5060; try changing the local port in the other device.
You can forward UDP port 5060 (or whatever Bind Port is set to) to the PBX, which will reserve the port number. In this case you’ll want to restrict which external addresses can send to Asterisk (with iptables or other firewall rules).
That is not 100% accurate. Plenty of carriers will honor the natted port without using registration. Also as the OP clearly states the carrier is using natted port just fine for everything except the BYE request.
The OP’s INVITE has the rport tag in the Via header, which tells the server to send replies to the address and port from which the request was received (ignoring the address in Via). Per the RFCs, this does not affect the destination of new requests sent by the server to the address in the Contact header.
I’ve not tested this, but it’s possible that setting NAT for the sub-account in question on the Vitelity portal will cause dialog-related requests to be sent to the translated source port, even with IP authentication.
@avayax , does your firewall provide a way to avoid the source port translation?
You can set NAT=YES on the portal only for subaccounts. The problem with the BYE does not occur there, they are sent to the source port.
With IP authentication you aren’t using subaccounts, but “IP address points” and you can’t set “NAT” there.
Not sure, but my guess is yes, I have to look. Using pf.conf on OpenBSD.
I am forwarding port 5060 to the PBX, but whitelisting IP addresses for inbound servers.
Didn’t think it would be necessary to include the IP address for the outbound server cause PBX is always initiating traffic to that IP first.
I guess if I also port forward traffic coming from the outbound server IP, the problem will be fixed then.
Having your port forward include the outbound server addresses seems like the best solution, if it works. It’s easy to try and IMO has no significant security risk.
Again my point stands. You can use peer to peer trunks and have the carrier use the natted port. Nothing says you can’t do that and we have plemty of customers who we do that for without a registered trunk. Your carrier just has to support it.
I assume that you are talking about SIPStation here. I hope that this behavior is optional, in which case it’s a useful feature. With AnveoDirect, it’s mandatory and that precludes it from being used with certain devices; see [Anveo] Anveo Direct with OBI - VOIP Tech Chat | DSLReports Forums .
However, unless you have an absolute external constraint (e.g. the customer or your boss says it must be done this way), it’s IMO not a good idea to build a system that by design will only work with a limited selection of trunking providers. In the OP’s case, there appears to be a simple fix with essentially no downside.
BTW, this issue is not directly related to registration. Most providers for whom IP authentication is not mandatory will accept outbound calls (using HTTP digest authentication) without registration. And, if they allow a DID to be routed to a SIP URI, incoming calls also don’t require registration. Examples include Callcentric, VoIP.ms, Anveo and Localphone.
I see in your invite you include an rport in your Via header without specifying a value, packet included below. Please correct your server settings to include proper values on your invite headers to avoid this issue.
Does this make sense?
Is there a way to not only force responses to be sent to the source port (which I believe the rport parameter does), but also force that behaviour for subsequent requests?
Unfortunately not at Vitelity, though some other providers, including SIPStation as noted by @tonyclewis , have this option.
Not quite true; conforming with the RFCs, they send to the address and port specified by the Contact header (a simplification which is accurate in the absence of Route headers). My Asterisk is on a non-standard port and it works fine with Vitelity.
A little history: The father of SIP, Dr. Henning Schulzrinne, is also the CTO of the US Federal Communications Commission. Although I greatly respect him as both a scientist and a politician, his political views have in some cases affected technical standards. He realized that IPv4 addresses would soon be exhausted, resulting in international bickering over allocation of the remaining space. Accelerated adoption of IPv6 was the solution. Since port-translating NAT is not needed with IPv6, he felt that the NAT-unfriendly aspects of various protocols would hasten IPv6 adoption. You may find Interview with Prof. Henning G. Schulzrinne - EEWeb interesting.
Are you using IP authentication to their SBC or sub accounts?
Vitelity told me with customers being on their SBC using IP authentication, they only sends signaling to port 5060.
I will try tomorrow with pjsip port 5160.
I am using a sub-account, because when IP authentication is specified, the default port 5060 is shown and cannot be edited. I didn’t bother to open a ticket about that, as I’ve had no trouble with lost registration and the only DID I still have with them is a little-used toll free.
I do use IP authentication with other providers, all of which allow the SIP port number to be entered on their portals.
I’m not sure what’s going on for you, but we do this all the time. And no, I’m not really an expert.
We mostly use IP routed trunks, but we’ll use registration when necessary (or when the customer asks). Vitelity says the IP routing is best. It’s certainly easier. We mostly use static IPv4 public addresses everywhere, or use registration.
The router you are using can make a difference…we usually use Mikrotik routers. SIP ALG turned off, pretty much always.
We rarely, if ever (anymore) put PBXs directly on the Internet. We use port forwarding almost 100% of the time. And we (mostly) firewall by source address (lists) to limit traffic just to the ITSP.
This is a bit old now. Mikrotiks can now accept hostnames as well as individual IP ranges.
