[Spce-user] Hair-pinning through SPCE - Loss of RTP Traffic

[Gary Nieboer]

Andrew,

Thank you so much for your assistance.

There is no NAT between the FreePBX and SPCE, The FreePBX and SPCE each use
their own IP address for media and signaling.
There are two carrier peers involved which both use different IP addresses
for media and signaling.  There is also no NAT between the carriers and
SPCE.   The signaling comes from a single IP at each carrier, but a range
of IPs for the media.   The carriers' proxies cannot reach the FreePBX IP
address.  Only the SPCE can reach both FreePBX and Carriers without NAT.


config.yml   has the following line:

nattest_exception_ips ~

Is the above variable for potential media proxy IP address(es) or signaling
proxy IP address(es)

How do I define a range of IP addresses?   Let's say I want to include
10.0.0.0 - 25.255.255.255

How do I define a list of unique IP addresses?   Let's say I want to
include 10.5.6.7   10.11.12.13 and 42.43.44.45

Thanks for your assistance.

-Gary


On Sun, Jul 13, 2014 at 3:30 AM, Andrew Pogrebennyk <
apogrebennyk at sipwise.com> wrote:

> Hi Gary,
>
> first my guess: is FreePBX on private IP? Does it proxy media? If it's
> private then SPCE receives INVITE from the RFC1918 IP and lb will
> overwrite whatever IP stands in the SDP with packet source IP. NAT check
> is sometimes causing troubles if media address is different from
> (private) signaling address, not sure whether this is the case or not,
> but in that case we recommend to whitelist signaling IP in
> nattest_exception_ips in the config.yml.
>
> On 13/07/14 04:30, Gary Nieboer wrote:
> > If the SPCE is version 2.8, everything appears to work fine in the above
> > scenarios.
> >
> > If the SPCE is version 3.2.1   or 3.3.1, then we have this failure.
>
> I can't think of any changes that could affect this. Check the
> /var/log/ngcp/rtp.log for messages "Confirmed peer information for port
> xyz". This means the first RTP packet has been received from either side
> on the mediaproxy port. Try comparing this log with the trace to find
> which side is not sending any media. Make a trace with RTP when unsure.
>
> > I read about a feature enhancement with 3.x, and it included a new
> > variable:   bypass_rtpproxy   We would like the SPCE to proxy all rtp
> > and potentially it is trying to bypass since both calls through the
> > FreePBX are from the same IP.   Where might we find this variable?
>
> It will be in the next 3.4 version actually and is in the 3.3 release
> notes by mistake.
>
> Hope this helps.
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140713/8f0af941/attachment-0001.html>