after i migrated to a new firewall model calls get dropped after about 30 sec.
i am not sure from where the issue is,i run test in firewall that nat is geeting to the voip server.
i am not sure from where the issue is.
from my fw: didnt see ay drops
i cant uploaded logs or put link to freepbx as forusm doesnt allow to upload for new users which is funny
You can upload them to a pastebin server. Preferably pastebin.freepbx.org, and post the URL or the last part of it. (You can also post the full URL as pre-formatted text.)
Blocking new users from uploading images is not unusual, as inappropriate images can put site operators into quite difficult legal positions.
The most likely causes of your problem is that you have not specified the correct external address, or that the remote side is behind NAT and isn’t giving the correct contact address, and you haven’t enable rewrite contact to compensate.
You’ve screen scraped this, rather than used the log files, which means there is a lack of timing information. However that log shows a call cleanly terminated by the Linksys. Did the callee receive any audio?
Note you are using a version of Asterisk that is no longer supported, and, although it still has about 3 months of security fixes left, you have not applied the latest security fix.
I can tell that something claiming to be a Linksys/SPA3000-3.1.10(GWd) dropped it. If that is your router, you need to disable SIP ALG in it. This is on the outbound leg.
i checked all what you said, but still we didnt advance.
i didnt find on linksys spa 3000 to disable sip alg, but i disabled sip alg in my firewall.
i went through configuration of spa 3000 and everything is configured well.
under Asterisk SIP Settings i have the correct external ip and correct internal networks.
please suggest how do i advance from here i need to know from where is the issue, if yu need further screenshots or logs please let me know.
Disable SIP ALG was based on your correctly identifying the Linksys device, in the logs, as being a router. I thought it probably wasn’t, which I gave the full identity and said “if it is your router”.
The UDP timeouts are orders of magnitude too small, but they wouldn’t cause the call to be cleanly terminated, but rather for one end to end up repeatedly retransmitting and not reahing the other. It is best not to rely on timeouts, and to use locked down port forwarding rules.
Just noticed that you are getting retransmissions, in the latest log.