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

[Florent Krieg]

Hi Ken,

Thanks for pointing this out.
I guess the value you have mentioned are overwritten by the following
settings in switch.conf.xml (which I have set)?
    <!-- RTP port range -->
    <param name="rtp-start-port" value="20000"/>
    <param name="rtp-end-port" value="40000"/>

Florent

2014-09-25 19:38 GMT+02:00 Ken Rice <krice at freeswitch.org>:

>  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.FreeSWITCH.org>
> http://www.ClueCon.com <http://www.ClueCon.com> http://www.OSTAG.org
> <http://www.OSTAG.org> *irc.freenode.net #freeswitch
> Twitter: @FreeSWITCH
>
>
> _________________________________________________________________________
> 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/20140926/0b1f16cf/attachment-0001.html