I have been having an issue with dropped calls with errors showing in the logs of “timeout on non-critical invite” which then drops the call. The provider has asked that we check on the packet transmission time which they are claiming is set to 150ms rather than the 20ms that they are looking for. Is there a setting for this or where would/could I make this change? Seems like an unrelated problem but I need to check.
That is a NAT issue. You need to disable any NAT that your Router/Firewall is doing, or, enable TLS transport to your provider.
@xrobau Thanks Rob, That’s what i keep telling the provider but they aren’t listening at this point. The router is controlled by them, I don’t have access to their config.
Thanks for getting back to me.
Well, you still have the other options.
- Use TLS. This stops the router messing with the traffic
- Use a wildly different port for your SIP traffic - port 6090 or something.
Also make sure that your nat settings are correct in Settings -> Asterisk SIP Settings.
We didn’t have NAT enabled before and still had the same problem. We enabled NAT to see if that helped but still the same. We have run the SIP debug for a week now and have relayed to the provider the SIP dialogue that shows the Re-transmission waiting for an ACK before the system terminates the call. They are still claiming its an issue on our end.
If your Asterisk server does not have a public IP address, nat must be enabled.
The config of the SIP connection is a little backwards. The SIP provider is also the ISP so they have a coax modem in the office with a Cisco 880. The modem port runs into the LAN port on the 880 and our PBX goes into the WAN port of the 880 directly from the PBX network port. This allows the ISP to trace right up to the point of connection. There is no other hardware in between the 880 and our PBX so the only config we have control over is the PBX. We were provided an IP which is within the same subnet of their router. That’s as far as our config goes with them. We enabled NAT to see if there was an issue with transferring through their router but that hasnt helped. My feeling is either their Core isn’t providing the ACK periodically or its being blocked by their router config.
Does it have a Public IP Address? If not, enable NAT. Make sure your Nat settings are correct in Admin → Asterisk Sip Settings.
You may also need to put nat=force_rport,comedia in the trunk
We are on the “public” side of their router so in a sense our PBX has a static IP in a “public” domain. The other side of their router VPNs directly to their systems and to their Core. The remainder of the switching happens on their end. We enabled NAT with the External IP that they gave us and everything is registering and calls are completing properly with the exception of the aforemention timeouts… As far as i can see the NAT config is correct.
Is it really a public IP?
One to One NAT is still NAT and localnet and externip must be populated correctly and NAT enabled locally.
Here is list of RFC5735 reserved IP. If your server has one of these your provider is doing NAT for you.
Here is the layout of the system. Normally a connection would run from the LAN side of a network to the SIP provider on the WAN side of the router. You program the PBX NAT with the external IP of the Router to replace the IP header with the external address of the router to ensure the returning packets are returned to the right IP, correct? In our case the provider has installed a router in our office and we are connected to the WAN side of THEIR router. There is no other hardware in between our PBX and their router.
The provider is now saying that the lack of the UPDATE option in the Allow header is what is causing the drops…
This is their header:
Allow: INVITE,BYE,CANCEL,ACK,REGISTER,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,INFO,REFER,OPTIONS,PUBLISH,PRACK
This is ours:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Why would the lack of UPDATE drops calls when we are seeing the timeout on non-critical invite message?