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

Tue Sep 30 12:59:48 MSD 2014

Hi all,

No one has a clue about this use case?
Can anybody confirm what Steven wrote earlier (i.e. 'So before the INVITE
is even sent the port is open')?

I just don't know how to behave here. I know it's a weird scenario and I
understand why it doesn't work but it happens so many times with customers
behind a NAT and I feel so close to a solution that I just can't stop
trying to find a solution.

Thanks in advance!
Florent

2014-09-26 10:26 GMT+02:00 Florent Krieg <flokrrr at gmail.com>:

> 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/20140930/5e61f299/attachment.html 