then FS seems to not be ready for it and reply ICMP unreachable.This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS.Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream?On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:_________________________________________________________________________FlorentThanks in advanceWould you know a way to solve this trouble? If you have any clue please share!My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet.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.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.When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX.customer1 IPBX <===> FS <===> PSTN_Y (redirection)PSTN_X <===> FS <===> customer1 IPBXSo there are two distinct calls:* 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...)* our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS)* we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT)Hi mates,We are encountering a problem with some of our customers in the following situation:
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.
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?
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org