[Freeswitch-users] RTP flows and device doing a local redirection

Florent Krieg flokrrr at gmail.com
Thu Sep 25 17:59:53 MSD 2014

Hi mates,

We are encountering a problem with some of our customers in the following
* we are running Freeswitch with a public IP address, detecting far-end nat
traversal when needed (customers behind NAT)
* our customers interconnects their IPBXes to our FS platform (we do only
SIP trunking with FS)
* if the customer has its IPBX behind a NAT and sets a local redirect,
there's no sound (and I completely understand why, I'm just trying to find
a solution, if any...)

So there are two distinct calls:
PSTN_X         <===> FS <===> customer1 IPBX
customer1 IPBX <===> FS <===> PSTN_Y (redirection)

When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX.
The IPBX then sends an empty RTP packet, I reckon to allow the remote
platform (FS in this case) to be able to detect the IP/port couple where to
send RTP packets.
The problem I have is that on the 'caller' side, this single empty RTP
packet is sent by the IPBX before sending the 200 OK (like, a few ms
before) and then FS seems to not be ready for it and reply ICMP unreachable.

To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold'
to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.

My idea is that the IPBX should send the 200 OK first and right after this
empty RTP packet.
The problem is I'm encountering the issue with two different constructors
(on one of them we ended using STUN, but the other one has a terrible STUN
implementation, hence I'm really looking for a solution).

I know it's tricky (SIP, NAT, redirection and so on) but what do you think
about this use case?
Would you know a way to solve this trouble? If you have any clue please

Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140925/7a46109e/attachment.html 

Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list