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

[Ken Rice]

Keep in mind that FreeSWITCH does not use the 20K to 40K range for RTP by
default. It used 16384:32768 so your iptables rules there will probably
cause a problem when FS tries to do media in the lower part of the range


On 9/25/14 10:54 AM, "Florent Krieg" <flokrrr at gmail.com> wrote:

> 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
> 
> 
> 
> _________________________________________________________________________
> 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

-- 
Ken
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
irc.freenode.net #freeswitch
Twitter: @FreeSWITCH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140925/86c0fbdf/attachment.html