One Way Audio – Doesn’t Seem To Be NAT Issue
I have been banging my head against the wall for weeks now on this one. I have a switch running NetBSD and Asterisk 11.19.0 although I
have had this problem on older versions as well. I, and my users, can call out, we can receive calls, quality is excellent but I cannot talk with one user. The different elements are as follows:
The switch as described above which is in a server room on the Internet backbone with a public IP address.
My home system which is behind a bridged modem through a Linksys WRT54GS with priority given to my ATA. The ATA is a Cisco SPA112. I
also have an actual SIP phone. The problem happens with both. Obviously I am using NAT but both devices work just fine if I am going to the PSTN.
My user who is also going through a bridged modem to a Linksys SPA-2102
which is doing the PPPOE so it has a public IP address and no NAT
involved although it serves NAT for the connected computer.
So here is the problem. While both of us have no problems externally, when we call each other we get one way audio and it is always from me to him no matter who initiates the call.
A further test, I can call from the SIP phone to the ATA connected phone and vice versa just fine. That involves two devices behind the same NAT but since they still need to use the server as an intermediary I can’t see how that would matter.
Given that both of us can make and accept calls and the server is simply connecting two separate channels I can’t see where the problem might lie. Can anyone suggest a possible setup issue?
I have tried so many things but I am willing to try them again. Feel free to make any suggestion no matter how silly. I really need to fix this.
Cheers.
5 thoughts on - One Way Audio – Doesn’t Seem To Be NAT Issue
I’d suggest getting a packet capture to see the RTP traffic to see the actual path of things, not just thinking of what it should be. Media doesn’t just get lost. It’s told to go somewhere ultimately and either that is incorrect for some reason or something is blocking it.
Cheers,
Hi D’arcy
Have you checked your RTP port ranges (I’m sure you have), and also that the server IP for RTP as specified in the initial SIP is correct?
Not sure how this will relate to your setup, but we had something similar here using Asterisk 1.8.11.0 on both sides of the connection, via a VOIP
service provider in the middle.
We had slightly different parameters, e. g. that we would have no RTP at all, but a call that did connect to total silence, dialed from either side.
We subscribe to two trunk numbers provided by the VOIP service provider at each site in Asterisk.
It turned out after carefully looking at the SIP flowing back and forth that the service provider was providing an RTP server IP that specified not the same IP as the SIP server (which is their standard practice) but a
-different- RTP server IP.
Due to the routing we have, neither system on either side of the SIP
negotiated call could send packets to this “new” RTP server IP.
We therefore added a route that specifically allowed that “new” RTP server IP to be reached by both machines on both sides of the VOIP service provider link.
So can you carefully check that the SIP-negotiated RTP streams are going to IPs that are reachable in BOTH directions?
Also check what RTP port ranges are being used – I have had this one-directional problem where the port range in /etc/asterisk/rtp.conf was too broad, and the firewall on my server was only allowing a smaller subset of RTP ports.
E. g. /etc/asterisk/rtp.conf specified 10000 – 50000 as allowable RTP ports, but my firewalld firewall under CentOS was only allowing 10000 – 20000 – so I’d regularly get that my SECOND call to test the server would have audio in one direction – because Asterisk was allocating an RTP port on one side of the SIP call that was outside the range my firewalld was allowing.
It might require some careful tracing of SIP messages, maybe you can try this? Specifically try to determine what RTP port number is being negotiated when you have your zero-audio back from the remote party – what RTP port and RTP server IP is he using at that moment on his side?
Is that port allowed through all the PPP / network segments between you? Is the IP / IPs between you used to transfer RTP reachable from his side?
Message: 1
Date: Tue, 11 Aug 2015 15:10:44 -0400
From: “D’Arcy J.M. Cain”
To: “Asterisk Users Mailing List – Non-Commercial Discussion”
Subject: [asterisk-users] One way audio – doesn’t seem to be NAT issue Message-ID: <20150811151044.79872ce9@imp>
Content-Type: text/plain; charset=US-ASCII
Given that both of us can make and accept calls and the server is simply connecting two separate channels I can’t see where the problem might lie. Can anyone suggest a possible setup issue?
I have tried so many things but I am willing to try them again. Feel free to make any suggestion no matter how silly. I really need to fix this.
Cheers.
Yes. The ATA is using a range well within the range open on the server.
Both the server and client are outside of NAT so I don’t know what this might mean. They both have public IPs.
This is an Asterisk server talking to an ATA.
Was NAT involved?
rtpstart000
rtpend 000
which is exactly what my packet filter allows through.
I will check that.
Thanks for your suggestions.
Hi D’Arcy
might mean. They both have public IPs.
This was a problem we had when the RTP server negotiated in SIP with our VOIP ITSP on one side of the connection, differed from the IP we were expecting on that side of the connection and was blocked in our firewall.
Once we perused the SIP traffic we noted this and added the extra IP to the firewall for RTP traffic.
Yes, NAT was being done at both ends, but it turned out that NATing was not the problem.
I assume you have tried turning your packet filter or firewall off completely (just for a moment) to see if it helped?
Not 100% ure, but maybe play with the canreinvite or directmedia settings.