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

Andrew Pogrebennyk apogrebennyk at sipwise.com
Sun Jul 13 05:30:33 EDT 2014

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.

More information about the Spce-user mailing list