No audio on one way

Status
Not open for further replies.

mrclassic

Joined
Sep 20, 2007
Messages
35
Reaction score
0
Hello dear readers

I know... there are quite a few posts regarding audio problems however I could not find a solution for what I'm fighting with.

My 3CX Version 7 is sitting in a DMZ on a public IP. The phones (all Linksys) are sitting in the LAN on a private address. VOIP provider and phone are all shown as "registered". Stun has been turned off.

Internal calls work fine. Incoming calls from outside work fine.

The only problem are outgoing calls to an external number: In that case there is no audio on the internal phone. The external phone can hear me but not the internal can't.

Does not make sense to me, specially because audio is fine when the call is initiated externally.

Any ideas?
 
Did you verify your NAT settings? I’m just asking… :?:
It seems that port forwarding is not reaching your server IP.
 
Maybe a good clue but I don't exactly understand how you mean it? The server is on a public IP so there is no need to forward any ports. Only the phones are behind NAT in a private subnet.
 
Hi

Can you please give some more detail on the setup.

Does the router have multiple public IP addresses? Does 3CX have only 1 NIC? I simple network diagram would help.

Can you possibly attach a capture of a problem call?
 
mrclassic, what I am trying to tell you is that sometimes, for example when you are using a Sonicwall firewall, NAT is a real nightmare because the default dynamic NAT, and I do not know how your network is configured.
As William said, post your network diagram, including router config, that way we will try to help you.
 
Thanks guys for taking care of me.

Sonicwall is a good guess, I am actually using a Sonicwall NSA 3500. The setup is IMHO pretty much standard and quite simple:

WAN
|
Cisco Router (32 Public IPs, up to here managed by provider)
|
Sonicwall
| |
| -- DMZ in transparent mode with servers (including the 3CX) running on multiple static public IPs
|
-- LAN with IP phones and workstations (private net behind NAT 192.168.xxxxxx, IPs dynamically assigned by DHCP)

All ports open from LAN->DMZ. From WAN->DMZ only the necessary ports are open, for VOIP: TCP/UDP 5060-5066 and UDP 9000-9049
SIP Transformation is enabled in Sonicwall. "Enable consistent NAT" is disabled by default, tried to enable but no change.

The 3CX server has only one NIC, only 1 public IP bound to it.

To repeat the problem:

LAN IP Phone <-> LAN IP Phone: OK
Outside PTSN Phone -> LAN IP Phone (through 3CX): OK
LAN IP Phone -> Outside PTSN Phone: No audio on LAN IP Phone
LAN IP Phone -> 999 (Voicemailbox on 3CX): No audio


Maybe the problem is indeed coming from the Sonicwall, integrax - do you have a hint what options I would need to look after?
 
mrclassic,

There is a known topic regarding issues about config Sonicwall equipments to work with VoIP, mainly because “For security reasons” Sonicwall do not allow you to disable dynamic NAT. :?: :?: :?:
Nick Galea has documented this several times and as he say, this is an issue with sonicwall and ANY VoIP phone system.
Please take a look at this two post to know more about:


http://www.3cx.com/forums/sonicwall-tz-7885-15.html#p42625


http://www.3cx.com/forums/sonicwall-tz170-enhanced-configuration-7647.html#p39009
 
Thanks for the links. Looks though like these guys have a bit of a different setup and problems. Unfortunately it was not clear to me what settings cause what behaviour.

One was having his 3CX server in the local LAN and then using the STUN server. Would that be more recommendable instead of putting the server on a public IP in the DMZ and leave STUN away?
 
Dear mrclassic,

3CXMediaServer.trace.log file (in verbose mode) provides complete information about audio routing (for each call). This information may provide a good input for your investigation.

Regards
 
Here is that MediaServer trace file.

I was calling the Voicemailbox (999) from internal IP phone 192.168.168.22
 

Attachments

Am I the only one with such a problem? Am I the only one running 3CX on a public IP? Is it really the Sonicwall causing so much trouble?

I would love to finally throw out our old Siemens PBX but first an VOIP solution must work.
 
mrclassic said:
Here is that MediaServer trace file.

I was calling the Voicemailbox (999) from internal IP phone 192.168.168.22

Question, how that log is correlating with your initial post:
Internal calls work fine. Incoming calls from outside work fine.

The only problem are outgoing calls to an external number: In that case there is no audio on the internal phone. The external phone can hear me but not the internal can't.

Does not make sense to me, specially because audio is fine when the call is initiated externally.

Thanks
 
SY: Well, it is how I wrote it... I can call other internal phones (same LAN segment) and audio both ways is ok. But when I call the Voicemailbox (999) I don't hear audio.
 
mrclassic said:
SY: Well, it is how I wrote it... I can call other internal phones (same LAN segment) and audio both ways is ok. But when I call the Voicemailbox (999) I don't hear audio.
Could you please provide output of "ipconfig"?
It looks like the routing of UDP packets from PBX host to local network has some problems. Do you hear the "music on hold"?(in case of successful internal calls)
 
mrclassic, try to enable also 7000-7499 range of ports. It seems MS uses it for external calls too. I don't have enough info to explain why, though. But does it really matter? :)
 
SY: There is not much to see in the IPconfig except for my IP 195.141.xxx.230 Subnet 255.255.255.224 and Gateway 195.141.xxx.1

Archie: I don't understand on what inferface you want me to open these ports? From LAN (where the phones are) to DMZ (3cx Server) or WAN these ports are not blocked. The other way around from DMZ or WAN into the LAN they are blocked. For security reasons it's not possible to open ports into the LAN.
 
mrclassic said:
SY: There is not much to see in the IPconfig except for my IP 195.141.xxx.230 Subnet 255.255.255.224 and Gateway 195.141.xxx.1

Archie: I don't understand on what inferface you want me to open these ports? From LAN (where the phones are) to DMZ (3cx Server) or WAN these ports are not blocked. The other way around from DMZ or WAN into the LAN they are blocked. For security reasons it's not possible to open ports into the LAN.

Second part of my question was related to "music on hold". Does it work in context of successful "local" calls? Do you hear it(music) if call is put "on hold"?
 
You've mentioned:

mrclassic said:
All ports open from LAN->DMZ. From WAN->DMZ only the necessary ports are open, for VOIP: TCP/UDP 5060-5066 and UDP 9000-9049
SIP Transformation is enabled in Sonicwall. "Enable consistent NAT" is disabled by default, tried to enable but no change.

So do the same for 7000-7499 ports range as you've done for 9000-9049
 
Mr.Classic,

I'm here to report that you're not the only one with this issue.
I currently have a very similar setup to Mr.Classic

I have a dedicated public IP 'mapped' to the internal IP of our 3CX server at 10.10.1.200
A mapping in this case means that all traffic inbound on our public IP gets routed to 10.10.1.200
All traffic going to the outside world travels along our public IP of xx.xxx.xxx.237

So my question is this... why is it much like MrClassic that I can not hear voicemail or hold music.
When I speak into the SPA962 Handset deployed at my house, I can hear myself on an external phone that I called.
But when speaking into the external phone I cannot hear myself on the Linksys SPA962.

The linksys at my house is behind my home IP address. Opening ports to these phones from the home router home is NOT an option.
We need a solution that will work without users reconfiguring their networks.

The Linksys phone at home is set to connect on the external IP address of xx.xxx.xxx.237

Any assistance is greatly appreciated.
Matt

3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.

<21:38:24>: Phase 1, checking servers connection, please wait...
<21:38:24>: Stun Checker service is reachable. Phase 1 check passed.
<21:38:24>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
<21:38:29>: UDP SIP Port is set to 5060. Response received correctly with no translation. Phase 2a check passed.

<21:38:29>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
<21:38:33>: TCP SIP Port is set to 5060. Response received correctly with no translation. Phase 2b check passed.

<21:38:33>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
<21:38:38>: TCP TUNNEL Port is set to 5090. Response received correctly with no translation. Phase 3 check passed.

<21:38:38>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
<21:38:43>: UDP RTP Port 9000. Response received correctly with no translation. Phase 4-01 check passed.
<21:38:48>: UDP RTP Port 9001. Response received correctly with no translation. Phase 4-02 check passed.
<21:38:52>: UDP RTP Port 9002. Response received correctly with no translation. Phase 4-03 check passed.
<21:38:57>: UDP RTP Port 9003. Response received correctly with no translation. Phase 4-04 check passed.
<21:39:01>: UDP RTP Port 9004. Response received correctly with no translation. Phase 4-05 check passed.
<21:39:06>: UDP RTP Port 9005. Response received correctly with no translation. Phase 4-06 check passed.
<21:39:10>: UDP RTP Port 9006. Response received correctly with no translation. Phase 4-07 check passed.
<21:39:15>: UDP RTP Port 9007. Response received correctly with no translation. Phase 4-08 check passed.
<21:39:19>: UDP RTP Port 9008. Response received correctly with no translation. Phase 4-09 check passed.
<21:39:24>: UDP RTP Port 9009. Response received correctly with no translation. Phase 4-10 check passed.
<21:39:28>: UDP RTP Port 9010. Response received correctly with no translation. Phase 4-11 check passed.
<21:39:33>: UDP RTP Port 9011. Response received correctly with no translation. Phase 4-12 check passed.
<21:39:37>: UDP RTP Port 9012. Response received correctly with no translation. Phase 4-13 check passed.
<21:39:42>: UDP RTP Port 9013. Response received correctly with no translation. Phase 4-14 check passed.
<21:39:46>: UDP RTP Port 9014. Response received correctly with no translation. Phase 4-15 check passed.
<21:39:51>: UDP RTP Port 9015. Response received correctly with no translation. Phase 4-16 check passed.
<21:39:55>: UDP RTP Port 9016. Response received correctly with no translation. Phase 4-17 check passed.
<21:40:00>: UDP RTP Port 9017. Response received correctly with no translation. Phase 4-18 check passed.
<21:40:04>: UDP RTP Port 9018. Response received correctly with no translation. Phase 4-19 check passed.
<21:40:09>: UDP RTP Port 9019. Response received correctly with no translation. Phase 4-20 check passed.
<21:40:13>: UDP RTP Port 9020. Response received correctly with no translation. Phase 4-21 check passed.
<21:40:18>: UDP RTP Port 9021. Response received correctly with no translation. Phase 4-22 check passed.
<21:40:22>: UDP RTP Port 9022. Response received correctly with no translation. Phase 4-23 check passed.
<21:40:27>: UDP RTP Port 9023. Response received correctly with no translation. Phase 4-24 check passed.
<21:40:31>: UDP RTP Port 9024. Response received correctly with no translation. Phase 4-25 check passed.
<21:40:36>: UDP RTP Port 9025. Response received correctly with no translation. Phase 4-26 check passed.
<21:40:40>: UDP RTP Port 9026. Response received correctly with no translation. Phase 4-27 check passed.
<21:40:45>: UDP RTP Port 9027. Response received correctly with no translation. Phase 4-28 check passed.
<21:40:49>: UDP RTP Port 9028. Response received correctly with no translation. Phase 4-29 check passed.
<21:40:54>: UDP RTP Port 9029. Response received correctly with no translation. Phase 4-30 check passed.
<21:40:58>: UDP RTP Port 9030. Response received correctly with no translation. Phase 4-31 check passed.
<21:41:03>: UDP RTP Port 9031. Response received correctly with no translation. Phase 4-32 check passed.
<21:41:07>: UDP RTP Port 9032. Response received correctly with no translation. Phase 4-33 check passed.
<21:41:12>: UDP RTP Port 9033. Response received correctly with no translation. Phase 4-34 check passed.
<21:41:16>: UDP RTP Port 9034. Response received correctly with no translation. Phase 4-35 check passed.
<21:41:21>: UDP RTP Port 9035. Response received correctly with no translation. Phase 4-36 check passed.
<21:41:25>: UDP RTP Port 9036. Response received correctly with no translation. Phase 4-37 check passed.
<21:41:30>: UDP RTP Port 9037. Response received correctly with no translation. Phase 4-38 check passed.
<21:41:34>: UDP RTP Port 9038. Response received correctly with no translation. Phase 4-39 check passed.
<21:41:39>: UDP RTP Port 9039. Response received correctly with no translation. Phase 4-40 check passed.
<21:41:43>: UDP RTP Port 9040. Response received correctly with no translation. Phase 4-41 check passed.
<21:41:48>: UDP RTP Port 9041. Response received correctly with no translation. Phase 4-42 check passed.
<21:41:52>: UDP RTP Port 9042. Response received correctly with no translation. Phase 4-43 check passed.
<21:41:57>: UDP RTP Port 9043. Response received correctly with no translation. Phase 4-44 check passed.
<21:42:01>: UDP RTP Port 9044. Response received correctly with no translation. Phase 4-45 check passed.
<21:42:06>: UDP RTP Port 9045. Response received correctly with no translation. Phase 4-46 check passed.
<21:42:10>: UDP RTP Port 9046. Response received correctly with no translation. Phase 4-47 check passed.
<21:42:15>: UDP RTP Port 9047. Response received correctly with no translation. Phase 4-48 check passed.
<21:42:19>: UDP RTP Port 9048. Response received correctly with no translation. Phase 4-49 check passed.
<21:42:24>: UDP RTP Port 9049. Response received correctly with no translation. Phase 4-50 check passed.
 
Mr.Classic,

Which Linksys phones are you using?

I've got success to report by enabling the following options on my SPA962.
NAT Mapping Enable: YES
NAT Keep Alive Enable: YES

Both options are set to no by default.
If these phones are connecting on the Public IP make sure that the proxy and outbound proxy are set to the public IP address.
And set Use Outbound Proxy to YES.

EDIT: It appears that you must have stun enabled on the phone as well, even though I have STUN off on my server.
Here are my STUN settings
Enable : YES
STUN Server : stun.3cx.com
Stun Min Port : 3478

I've now got two different extensions on the same phone connected to my 3cx system at my office from my house, accepting calls and two way audio.

Matt
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
112,323
Messages
591,896
Members
165,474
Latest member
costionofrei