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

[Florent Krieg]

Hi Steven,

Thanks for the reply!

Here's the firewall policy (iptables, the FS service is hosted on a centos6
server):
-A INPUT -p udp -m udp --dport 20000:40000 -j ACCEPT
The port annonced by FS and actually used was in this range (34546). Hence,
I doubt the port s blocked.

There is still the possibility of the port not being listening.
This is comforting that you say it should be listening on it right before
the INVITE, but it is a bit weird I'm experiencing such a behaviour...

Steven, there are a lot of public IPs in my capture (among them some of
customers and I don't want to obfuscate it so I won't post it here), but if
you'd like I can send it to you by email so that you can have a look as
well?

Thanks
Florent


2014-09-25 17:06 GMT+02:00 Steven Ayre <steveayre at gmail.com>:

> 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 at gmail.com> wrote:
>
>> Hi mates,
>>
>> We are encountering a problem with some of our customers in the following
>> situation:
>> * 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
>> share!
>>
>> Thanks in advance
>> Florent
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> 
>> 
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> 
> 
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140925/dc07b798/attachment-0001.html