asterisk users - Aug 2015 - One way audio - doesn't seem to be NAT issue

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" <darcy at Vex.Net>
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
	<asterisk-users at lists.digium.com>
Subject: [asterisk-users] One way audio - doesn't seem to be NAT issue
Message-ID: <20150811151044.79872ce9 at 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.

On Thu, 13 Aug 2015 10:41:31 +0200
"Stefan Viljoen" <viljoens at verishare.co.za>
wrote:
> Have you checked your RTP port ranges (I'm sure you have), and also
Yes.  The ATA is using a range well within the range open on the server.
> that the server IP for RTP as specified in the initial SIP is correct?
Both the server and client are outside of NAT so I don't know what this
might mean.  They both have public IPs.
> 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.
This is an Asterisk server talking to an ATA.
> 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.
Was NAT involved?
> 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.
rtpstart=10000
rtpend=20000

which is exactly what my packet filter allows through.
> 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?
I will check that.

Thanks for your suggestions.

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:darcy at Vex.Net
VoIP: sip:darcy at Vex.Net

Hi D'Arcy
>> that the server IP for RTP as specified in the initial SIP is correct?
>Both the server and client are outside of NAT so I don't know what this
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.
>> 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.
>Was NAT involved?
Yes, NAT was being done at both ends, but it turned out that NATing was not
the problem.
>> 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.
>rtpstart=10000
>rtpend=20000
>which is exactly what my packet filter allows through.
I assume you have tried turning your packet filter or firewall off
completely (just for a moment) to see if it helped?