No audio on one way

[mrclassic]

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?

 

[archie]

We need a solution that will work without users reconfiguring their networks.

You have such a solution: use 3CX Tunnel. It works as long as you can establish TCP connection between home network and the network where PBX resides. It uses one single TCP connection so you're not affected with any NAT / routers on the path.

 

[mrclassic]

Matt: I don't think we have a similar setup at all, we only might have the same problem... I'm using Linksys 962, 921 and 942 phones. Enabling NAT Mapping or Keep Alive does not solve my problem.

SY: "Music on hold" does not work either.

Archie: Since I have already the audio problem calling to the VMB opening these ports on the WAN interface does not affect anything. Anyhow, I tried but as I thought - problem remains.

My problem needs to have some connection with transferring audio through RTP into the LAN where the Phones reside. The signaling does not seem to be a problem since the phones are ringing when they should.

 

[DXS_Matt]

We need a solution that will work without users reconfiguring their networks.

You have such a solution: use 3CX Tunnel. It works as long as you can establish TCP connection between home network and the network where PBX resides. It uses one single TCP connection so you're not affected with any NAT / routers on the path.

Archie, how are we supposed to setup our tunnel connection with Linksys SPA962 phones?

And MrClassic, I too had the same thing where the phone would signal, but no audio.
Did you make sure that you entered the STUN details? As my setup would not work without those.

Matt

 

[archie]

DXS_Matt,

how are we supposed to setup our tunnel connection with Linksys SPA962 phones?

Easiest way is to deploy 3CX Phone Client at some PC. It will deploy 3CX Tunnel. Than configure it to connect to PBX, and than point out "outbound proxy" of Linksys to local tunnel's SIP port. I'm sure there's more detailed description somewhere in FAQ or wiki.

 

[mrclassic]

Matt: I don't really see the logic behind enabling STUN in my situation since - as mentionned before - I don't have any problems with the signaling. And from my understanding the only thing STUN does is make a phone reachable. Anyway - just because weird things can happen - I tried with STUN now but no change.

 

[SY]

...

SY: "Music on hold" does not work either.

...

RTP traffic which is sent from PBX host doesn't reach the destination (local extension).
Information provided by "ipconfig" _may_ help to find the problem. It will be more informative if it will be extended with "route print" output.

Thanks

 

[nb]

Also did you try to change your setup slightly and put the router out of DMZ and behind NAT with proper port forwarding?

Try this also and let us know.

 

[mrclassic]

nickybrg: The whole point of having a DMZ is to avoid port forwarding into the LAN segment. It's a matter of security.

SY: I agree that RTP traffic for some reason does not seem to reach the destination. However I see no point for a routing problem specially since you cannot set separate routings for different protocols/ports in Windows. If SIP traffic reaches the destination then RTP should also.

 

[mrclassic]

I even tried to open all ports (SIP, RTP, 7000-7499) from the DMZ (3cx) -> LAN (local phones) and still don't hear the VMB.

 

[nb]

Actually your scenario is less secure than what you think in my opinion. Your PBX is part of YOUR PRIVATE ASSETS. it involves private telephone calls, billing information, voip provider accounts and Tel Lines hence it should go in a TRUSTED ZONE not placed in an Untrusted Zone like DMZ. Public Boxes which are used for public services go in DMZ (considered untrusted). But anyway - it is up to you to decide and in no way am I telling you what to do with your network. i would put something like Counterstrike gaming server in dmz not my PBX.

Now Sip and RTP traffic are different - we assume it is a routing problem. And the only thing you have not tried so far is to put your pbx inside your network. We need to rule out whether this is a pbx problem, a network problem or a router problem. Without tests you can never know. Also You cannot assume that if sip traffic reaches, rtp traffic must automatically reach. This is incorrect logic. They are separate. They run on different ports and are different services.

Also if you want to keep your router in DMZ, start a wireshark capture on that box and check what the pbx is receiving. If you dont see rtp packets - your next option is to syslog the router and see whether the packets are received by the router or not. If yes, simple - the router is dropping them or they are being sent somewhere else. First identify whether this is the case or not.

 

[nb]

I think you have a routing problem between the DMZ and your local lan.

Put one of the phones in DMZ and see if you can access Voicemail.

And put the pbx inside and see if you resolve voicemail. This should be the very first thing to troubleshoot - Voicemail.

 

[SY]

...
SY: I agree that RTP traffic for some reason does not seem to reach the destination. However I see no point for a routing problem specially since you cannot set separate routings for different protocols/ports in Windows. If SIP traffic reaches the destination then RTP should also.

I didn't try to enforce you to provide information, I had tried to help you (and meanwhile collect some pieces of information)... Excuse me, please

regards

 

[nb]

Hi Mr Classic

I would like to rephrase my first post as I was not entirely correct. The post I posted is only valid if you are using Host DMZ (the DMZ option that comes inbuilt in common home routers). In your case you are using real DMZ as your internal network is separated from your DMZ network and networks are on a different subnet.

I don't think that port forwarding of rtp ports (internal;7000 range and external;9000 range) will help in this case. AFAIK, reason being these ports are already open in DMZ and all ports will be forwarded to the host in dmz EXCEPT those ports that are specified in forwarding rules. You want the ports to be forwarded to the 3CX host machine and not to the internal LAN (since 3CX is not in the internal lan). Hence simple portforwarding will directly forward ports to the internal Lan skipping DMZ.

I think that the best way to go about this is to designate a public ip address to the 3CX server host followed with a one to one nat for the 3CX dmz'ted host server. Then create access rules on the firewall to allow intercommunication between connectivity initiating from DMZ to the internal lan. I think you will need the enhanced OS to configure this setup.

What I am still unclear on is why internal calls are failing audio - this is not possible because if the connection is initiated from the internal network, to the DMZ, (case in point a call to voicemail) it is trusted as it originated from Inside. This leads me to believe that there is some setting set in the Sonicwall that is modifying outgoing messages to the server leading to audio being sent back translated to another port other than that of the initiating phone. There has to be some setting in the sonicwall to prevent this behavior. Your next step in my opinion is to try and understand (through logs/captures) where the missing audio leg is being sent to. From the results you will be able to conclude what type of NAT or translation is occuring between internal and DMZ and vice versa.

I would study the access rules section and available options carefully. This device is very flexible and supports multiple configurations.


Reading further there are two problems in this thread and it is good to distinguish between them - DXMATT AND MRCLASSIC - both have the same symptom but different scenarios completely.

DXmatt - when you suggested to Mrclassic to enable stun, it worked fine for you but MrClassic's case is different. You need Stun because you are phoning from home hence you have an external extension setup on the linksys to the PBX. Therefore the linksys needs to know the public address of the network it is residing on at the moment to be able to send proper contact information to the pbx and get reached back. This is because the 3CX server is somewhere on the internet WAN side. Stun is a must in your case. To be fair all you need is stun because the Linksys will do the rest with its routing table. Mr Classics case is completely different (although the symptom of 1 way audio is the same). In Mr Classics case, enabling stun on the phones will continue to break his setup - The phones are on the internal lan - they have no interest in knowing what the networks public ip is because their 3CX server is somewhere they are able to reach - beyond the backend firewall in dmz zone.

 

[mrclassic]

SY: I did not meant to be rude or something, I really appreciate to get any answers and help. I still think the local routing table of the server has nothing to do with the problem. The entries are just standard.

nickybrg: Thanks a lot for this extensive post. You are correct, my Sonicwall DMZ is a "real one". Actually the way it is set up in transparent mode means that I can directly assign public IPs to the DMZ servers. There is no need for any 1-to-1 setup or similar. Also I believe I opened all necessary ports into the DMZ and also from DMZ to the LAN. You might have mistunderstood that internal calls are failing audio. They are only failing audio when calling the voicemailbox, calls from one internal phone to another are working fine.

As someone suggested I have installed a 3CX server in my LAN but I don't know what went wrong here. Now I cannot even call the voicemailbox, I get immediate busy signal and the log says "Attempt to reach <sip:[email protected]> failt. Reason: Not registered". Besides that I have the same problem: When calling external numbers there is no audio coming in.

I have meanwhile also filed a request with Sonicwall. They gave me some technical documentation to read which I will do. Maybe I can get something out from there.

 

[mrclassic]

A little update for those that still stick to the thread: I have updated my Firmware on the firewall as suggested by Sonicwall. Also read through the provided documents however without discovering anything new. According to Sonicwall the PBX (SIP Proxy Service) may be located in the LAN or DMZ. My problem remains unsolved.

 

[mrclassic]

To close this thread I wanted to post a little update from my side.

After doing a lot of tests and packet captures I've found out that RTP traffic going to my Linksys phones uses ports 16384 to 16482. After I opened them I could hear the voicemailbox.