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

[Gary Nieboer]

I have been able to do additional testing.

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.



In addition, if an attended transfer or unattended transfer occurs through
the FreePBX, we don't have an issue.  However, if we just have the FreePBX
perform a Call Forward, then the call is not "complete" until it is
re-routed out the SPCE.  Then we lose audio.

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?

Please let me know if you may have any other ideas.

Thanks,

Gary



On Tue, Jul 8, 2014 at 2:24 PM, Gary Nieboer <gary at netdiverse.com> wrote:

> We are having an issue with calls that pass through the SPCE and hairpin
> through a FreePBX back through the SPCE and out again.  (Our FreePBX is set
> up to Call Forward Always to a PSTN number)   SPCE is connected to Carrier
> A  peer, and the outbound default peer.  SPCE is connected to FreePBX as a
> peer with a few peering rules.
>
> This only seems to happen when all 4 call legs to peers are passing
> through the same SPCE and 2 of the legs are to the same FreePBX.
>
> SIP signaling works great.
> We have no RTP in either direction on all 4 legs.
>
> Call Leg A:   Carrier A peer to SPCE
> Call Leg B:    SPCE to FreePBX-A peer
> Call Leg C:    FreePBX-A peer  to SPCE
> Call Leg D:   SPCE to Carrier A
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140712/11b2958b/attachment-0001.html>