One way Audio - External extentions to internal

[williamae]

This is a brief description about the topology
I am running 3CX v7 on windows Server 2008 R2 behind a Cisco ASA5505 8.2(1).
Two PAP2 and SPA3102 is connected and registered to 3CX
Problem is when I want to make a call from a remote extension to one of those local extensions; I have one way audio.
Whenever I VPN to the ASA5505 and try to make the phone calls I have no problem
Interestingly when I make phone calls between two remote extensions I have no issue at all and they can hear each other very well.
External softphones are Bria (iPhone Version) and Xlite.
I have to do a little port translation in ASA, because port 5060 is blocked by my ISP.
I tested whether port translation works fine by calling to SPA3102 remotely by my iPhone and there was no issue.
Although VPN is feasible solution but I don't want to use it.
Here is the firewall output for more clarification.
Also I changed the RTP port range from 9000-9049 to 16384-16482
3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.
<03:21:11>: Phase 1, checking servers connection, please wait...
<03:21:11>: Stun Checker service is reachable. Phase 1 check passed.
<03:21:11>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
<03:21:19>: UDP SIP Port is set to 5060. Response received WITH TRANSLATION 8090::5060. Phase 2a check passed with WARNINGS. Some functionality will be LIMITED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/

<03:21:19>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
<03:21:24>: TCP SIP Port is set to 5060. Response received WITH TRANSLATION 8090::5060. Phase 2b check passed with WARNINGS. Some functionality will be LIMITED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/

 

[williamae]

Rest of firewall checker report

<03:21:29>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
<03:21:55>: UDP RTP Port 16384. Response received WITH TRANSLATION 40135::16384. Phase 4-01 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:00>: UDP RTP Port 16385. Response received WITH TRANSLATION 33807::16385. Phase 4-02 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:04>: UDP RTP Port 16386. Response received WITH TRANSLATION 43494::16386. Phase 4-03 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:09>: UDP RTP Port 16387. Response received WITH TRANSLATION 11245::16387. Phase 4-04 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:13>: UDP RTP Port 16388. Response received WITH TRANSLATION 21756::16388. Phase 4-05 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:18>: UDP RTP Port 16389. Response received WITH TRANSLATION 33263::16389. Phase 4-06 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:22>: UDP RTP Port 16390. Response received WITH TRANSLATION 41734::16390. Phase 4-07 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/
<03:22:27>: UDP RTP Port 16391. Response received WITH TRANSLATION 23584::16391. Phase 4-08 check passed with WARNINGS. Some functionality may be IMPAIRED. For more information, please visit http://www.3cx.com/blog/docs/firewall-checker/

 

[cfive]

Why not use the 3cx tunnel? that should solve all the problems.

 

[leejor]

Why not use the 3cx tunnel? that should solve all the problems.

He could only use the tunnel if the remote sets were 3CX phones or he deployed the 3CX proxy server at the remote location.

Have a look in the 3CX log, are the remote sets registering with a private or public IP. It should be the public IP of the remote router. With the talk of 3CX STUN server issues recently, I'm wondering it that might be the cause.