PJSIP Softphone Extensions Won't Hangup (Zoiper)

General Help
1

We’re on:
FreePBX 13.0.192.19
Asterisk 13.17.2

We’re changing over from chan_sip because we continue to have Asterisk crashes when in our preferred configuration: TCP and non standard port for endpoint connectivity.

That said, as we’re testing, I’ve noticed calls placed to or from the popular Android softphone app, Zoiper, will not hangup. If the other endpoint hangs up, Zoiper thinks it’s still on a call. If Zoiper hangs up, the other enpoint does hangup, but Zoiper keeps saying “Hanging up” until you force quit the app.

I noticed DTMF default on server is RFC-4733, but Zoiper only has RFC-2833. There is SIP INFO numberic, SIP INFO symbolic, Inband, and disable as options on Zoiper. I’ve tried a few combinations of that, but no luck so far.

Is there another port other than the SIP signaling port I need to allow perhaps?

Thanks in advance.

2

I doubt that this issue is related to DTMF.

Several users have reported issues with the combination of TCP transport, non-standard bind port and Asterisk behind NAT. For example, see https://www.dslreports.com/forum/r31464501-Asterisk-TCP-transport-and-NAT-for-Asterisk and http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2014-June/017650.html . You can use
pjsip set logger on
at the Asterisk console to see if any Via or Contact headers sent by Asterisk incorrectly show port 5060.

I don’t know whether this bug has ever been properly reported, or even whether it is in Asterisk or in pjsip (I’m reasonably certain that it is not in FreePBX).

If you are using a non-standard port for security reasons, reverting to port 5060 but with more restrictive firewall rules might be a workaround. Or, connect through a VPN so the endpoint does not appear to be behind NAT. Or, put the PBX on a public IP address.

Sorry that I don’t have a good solution. (With luck, your issue may be different from the above, in which case there may be an easy solution. Check the relevant headers for port 5060.)

3

Thanks much. I will check those headers for sure.

For the record, our box is on a public IP. Just using iptables. No NAT. And yes, we use the non-standard port for security reasons.

Will try 5060 first to see if that eliminates the issue right away.

4

If it does solve the problem, be sure to submit a ticket with the pertinent security information obscured. This sounds buggish…

5

Will do thanks.

6

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