Remote Extensions dropping calls with 32 seconds - but only when port 5060 is forwarded

Friends, good afternoon!
I’m experiencing a curious problem on my FreePBX, which I believe is a problem caused by some misconfiguration in my network or in asterisk.

I have a Public IP associated with this PBX, and through it some people from our external team (home office) connect.

For security reasons, in my mikrotik I redirected port 7048 of the Public IP (186.215.xxx.xxx) to port 5060 of the PBX Private IP (192.168.1.140).

However, using this way, the calls originated by the extensions that are registered through that Public IP are dropping with exactly 32 seconds - only the ones that they originate, because they can receive calls perfectly.

I have already done all the procedures to resolve this, such as setting the Public IP in the NAT Asterisk settings, but unfortunately I was unsuccessful.

However, when I simply release port 5060 instead of redirecting port 7048 to it, the calls work perfectly - without dropping.

What could be causing this problem?
Thank you in advance for your attention and support! :grinning:

If that’s not your issue, please provide details:
Are the external extensions pjsip or chan_sip? Is the other driver also in use? Is the title of your post backwards?

Hi Stewart!
Thanks for the link!
I followed the instructions on it, but unfortunately it didn’t work - calls are still dropping with 32 seconds.

I only use PJSIP - the chan_sip driver is disabled.
Sorry for my bad english, i’m using a translator - and maybe the title of the post was mistranslated.
I mean that the calls are dropping with 32 seconds (not only outbound calls, but between extensions too) when i redirect a external port to 5060.
But, when the 5060 port are open to the world and i connect on it, the calls doesn’t drop (working normally).

Try setting the config manually. In
/etc/asterisk/pjsip_custom_post.conf
enter (or add to the end if there is already stuff there)

[0.0.0.0-udp](+type=transport)
external_signaling_port=7048

then restart Asterisk. At the Asterisk command prompt, type
`
pjsip show transport 0.0.0.0-udp
and confirm that external_signaling_port is properly set. Retest. If you still have trouble, paste the Asterisk log for a failing call (with pjsip logger on) at pastebin.com and post the link here.

Hello!
I did the procedure, and when running the command I saw that the external signaling port is correctly set.
The problem persisted, I activated the PJSIP log and copied the logs during a call initiated by my extension 2005 (test extension, which is accessing externally) to extension 2003 (which is in my internal network).

Here is the log: 6445 To: <sip:[email protected]>;tag=c96d034c-211d-46e0-9cea-cd8734b2bdf8 644 - Pastebin.com

PS: I copied these logs from the FreePBX “Asterisk log file” screen, to get the timestamp of the actions, and I used the “2005” filter to get only the information referring to that call/that extension, in case that causes important information is lost, I can also capture a full log (I used the filter to make it easier to read)

Unfortunately, the filtering destroyed the useful information. Please paste the entire sequence.

Oh, okay!
I apologize for the mistake.

Here is the complete log during the call:

We see the PBX sending the correct Contact header, for example log line 42050, but no ACK is received, the PBX retransmits to no avail and gives up after 32 seconds.

However, something is messing with the packets, as the initial INVITE shows a public IP in the Via header (log line 41396).

Unfortunately, I’m not familiar with either PortSIP or Vivo, so I don’t know where this may be happening.

Possibly, it’s in your own router. In IP → Firewall → Service Ports, check that the entry for SIP is disabled.

Next, see whether switching from Wi-Fi to mobile data (or vice versa) at the PortSIP end changes the symptoms. If not, are there any settings related to NAT or STUN in the mobile app? (I could not find a complete manual online.)

Otherwise, could you try shutting down PortSIP and running a simple softphone, e.g., MicroSIP on a PC at the remote site? This would rule out any NAT-related issue in the client, and would also allow us to compare the MicroSIP log with what we see at the PBX end. If you have some other Windows, Linux or Mac softphone available, we can use that; debugging on Android or iOS is difficult.

Hello friend, good morning!
I apologize for the delay in replying, the problem was really with my router.
After trying to understand what was wrong with it, I saw that it had outdated firmware, and after installing an update on it, everything worked perfectly again, even though no configuration had been changed.

I ran a series of tests to validate it and we saw that it is now working perfectly, thanks for your support!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.