Outbound Calls: Recipient can hear, but cannot talk back to caller

FreePBX 15.0.17.51

I woke up this morning and found that all calls made from the office are having issued not being able to hear the person they are calling.

The system CAN:

  • Receive calls
  • Transfer calls internally
  • Make calls
  • Target person called can hear the caller

The system CanNOT:

  • Allow the target person to talk back to the caller

Troubleshooting: The SIP provider is telling me the PCAP is showing:
“RTP being delivered to your IP XX.XX.XX.XX. I also show your internal IP is not sending an ACK back to us after the 200 OK.”

I do not know what to do next regarding further troubleshooting or remediation. Suggestions more than welcome, please.
Thank you

In Asterisk SIP Settings, confirm that External Address matches your public IP address. Pressing Detect Network Settings will likely set the correct value, but check to be sure. If you change this, after Submit and Apply Config you must also restart Asterisk.

If that’s not your issue, at the Asterisk command prompt type
pjsip set logger on
or
sip set debug on
according to trunk type, make a failing test call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.

Thank you for the response below is what I see:

https://pastebin.freepbx.org/view/12aee564

Updated with more details:
https://pastebin.freepbx.org/view/e5d8adbe

These are not the relevant times. The log for the call consists of several hundred lines. Also, the SIP traces are not there. When you type
sip set debug on
you should get a response
SIP Debugging Enabled
Also, note that Apply Config will disable this and you will need to turn it on again.

Here is the full Asterisk Log:
https://pastebin.freepbx.org/view/426df73b

Here is the FreePBX Log:
https://pastebin.freepbx.org/view/0663bbe0

The relevant section of the log is not present; it does not show any calls. The timestamps are in your local timezone. After setting sip debug and making your test call, please paste the section of /var/log/asterisk/full covering from just before you started the call until just after you hung up.

Thank you for sticking with me. I just did two calls with the team and below are the logs that were captured.
https://pastebin.freepbx.org/view/a9d8f00a

Am I missing something in the logs?

Yes, you are again missing the full SIP trace.

As mentioned, please run.

asterisk -rvvvvvv
sip set debug on

Reproduce the call and then copy the entire output starting from asterisk -rvvvvvv and paste into pastebin

I think I found the settings to get the log details.

https://pastebin.freepbx.org/view/9b3f53fc

Thank you!

In the log you can see the call to 18473665881, that is the test call that I can hear them, but they cannot hear me.

It appears that the problem is not with FreePBX/Asterisk, but with an SBC or ALG in the router/firewall(s) between the PBX and the internet.

Three lines starting at 3403:

<--- SIP read from UDP:64.2.142.189:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.7.10:5160;received=192.168.7.10;branch=z9hG4bK0a9d7d6e;rport=5160

This ostensibly shows that Vitelity received the INVITE from 192.168.7.10 . Obviously, that’s not possible because 192.168.x.x is a private address not routable on the internet. And, if you examine the INVITE (starting on line 3367), it does not contain 192.168.7.10 anywhere, so this couldn’t be a Vitelity issue as their server never saw 192.168.7.10.

Router/firewall make/model? What VoIP related settings (ALG, port forward, etc.)? Does it have the 96.60.x.x public IP address on its WAN interface? If not, what’s between that and the internet (ISP-supplied gateway, etc.)?

Thank you for the investigative work:

Router: Mikrotik 2011UiAS
Firmware: 6.48.1

VOIP dsnat:

  • WAN to FreePBX: tcp 443
  • WAN to FreePBX: tcp 80

WAN: 96.60.x.x
FreePBX Server: 192.168.7.10

The FreePBX server has the default firewall enabled as well.

Do you have your ‘sip service port’ (in firewall) set with the right ports and ‘sip direct media’ enabled ?

In the Mikrotik, IP -> Firewall -> Service Ports -> sip click the D (disable) button.
When you retest, if it still fails or fails in a different way, paste a new log.

Here are the settings.

image

I will disable and test.

If I follow the reasoning here, the expectation is that this will be the outcome, so don’t panic if this happens.

I performed several additional tests based upon everyone’s feedback. Unfortunately, I am remote from the office location and needed to use a VPN connection with a softphone to test with. The softphone did not the caller to send or receive audit (different issue), however, I was able to identify what was causing the issue with the person receiving the call not able to be heard.

I do not know why the new logs are not showing the <— SIP read details ----> (long day of user errors I guess)

Testing as requested:
Softphone: 2505
Phone # called: 470774xxxx

Disabled the: IP-> Firewall-> Service Ports-> SIP (5060, 5061)
Result: No change
Test 1: https://pastebin.freepbx.org/view/23041b5b

Enabled the: IP-> Firewall-> Service Ports-> SIP (5060, 5061)
Result: No change
Test 2: https://pastebin.freepbx.org/view/8e616b5b

Added the following Firewall NAT: dsnat->Dst. Address:96.60.X.X -> protocol:udp -> Dst. Ports: 10000-20000 -> To Address:192.168.7.10 -> To Ports: 10000-20000

Disabled the: IP-> Firewall-> Service Ports-> SIP (5060, 5061)
Result: Audio available from the person receiving the call
Test 3: https://pastebin.freepbx.org/view/067e1666

Enabled the: IP-> Firewall-> Service Ports-> SIP (5060, 5061)
Result: Audio available from the person receiving the call
Test 4: https://pastebin.freepbx.org/view/ad62dd47

Questions:
Seems the issue is related to me not opening the 10000-20000 ports to the FreePBX server.

  • Am I to allow a direct NAT to the server for those ports?
  • What are the best practices?
  • Why now? I did not have the ports open prior to this issue, almost a year.
  • Any ideas why the soft client (ZoiPer 2.17.8) would ending the call after 30ish seconds and was not able to send or receive audio?

Thank you

Unfortunately, none of the four tests included the sip debug info. When Asterisk is reloaded or restarted, sip debug (and pjsip logger) are turned off. After reload or restart, you have to re-issue the
sip set debug on
command to re-enable it. Since you had to configure a softphone to do the tests, it is not surprising that Asterisk was at least reloaded.

However, what’s strange is that the logs show that Asterisk was restarted right before each test, even though you were only changing router parameters. Did you do a restart on purpose? Were there any changes to the PBX config between tests?

In general, it is best practice to forward the RTP port range (default is UDP 10000-20000) to the private address of the PBX. It is necessary in some situations (such as forwarding an incoming call to a mobile) to get any audio. However, in the simple case of an outbound call from a local extension, it usually doesn’t matter, because audio from the extension is being sent out on the trunk, so audio from the trunk appears to the router as ‘replies’ and gets passed to Asterisk and eventually the extension. Although incoming audio would fail if Vitelity didn’t do ‘symmetric RTP’ (sending audio to whatever port it came from) and Mikrotik modified the source port number, I didn’t address that issue, because in your first post you noted that Vitelity also identified a signaling problem (lack of ACK), which forwarding RTP ports could not possibly fix.

Just guessing, a change at Vitelity affecting how they handle malformed SIP. Or, an ‘upgrade’ to Mikrotik modules that affected the strangeness of chan_sip binding to port 5160, which was not listed among the service ports. Or, some other device on your network that is using UDP ports in the 10000-20000 range, requiring the router to rewrite the source ports for your RTP.

Assuming that the OpenVPN client is on the same machine as ZoiPer and the OpenVPN server is on the FreePBX machine, possibly you forgot to include 10.8.0.0/24 in Local Networks (you must restart Asterisk after changing that). Otherwise, this is a complex setup and you need to describe the VPN config in detail.