[Freeswitch-users] OT: Apple goes to great lengths to defeat NAT and firewalls with new Facetime

[Steven Ayre]

>
> > That's not necessarily a given.
> >
> > In general though because the TCP connection explicitly signals the
> > connection closing the mapping will stay in the firewall. With UDP it is
> > removed after a long period of inactivity. That can cause problems with
> > signalling during a phone call unless the endpoints send keepalive
> packets
> > often enough.
> >
> > TLS will prevent the router helping with SIP ALG - you must have
> endpoints
> > capable of doing NAT traversal themselves (STUN). Though that's a good
> idea
> > in all cases anyway.
>   In my experience with a fairly large network and a number of
> endpoints TCP fragmentation is *much* more reliable than UDP
> fragmentation.  Various stateful firewalls also handle TCP much better
> (connection oriented and used by most applications people care about -
> more testing, etc).  Your points about keepalives and TLS are spot on
> although many devices don't have the "luxury" of keepalives due to
> issues with battery power.


For archival purposes (I suspect you know this)...

It solves the signalling issues, but the reason I said "not a given" is
that the RTP stream is still UDP. That means a call on hold can still lose
the port mapping. You still have the signalling, but that isn't much use
without the audio. You still need to obtain the correct ip:port for the SDP
to setup the RTP - STUN or SIP ALG, and RTP auto-adjust as a workaround for
bad addresses in some cases. SIP/TCP solves some of the issues, but not all.




On 20 September 2013 15:11, Kristian Kielhofner <kris at kriskinc.com> wrote:

> On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <steveayre at gmail.com> wrote:
> > Because SIP over UDP doesn't play well with fragmentation. SDP can make
> > packets large than the PMTU, leading to fragmented packets, which leads
> to
> > devices ignoring the packet. Removing the unnecessary rtpmap lines means
> > smaller SDP so smaller packet so less likelihood of that being an issue.
> >
> > It shouldn't be such an issue over TCP.
> >
> > Devices *should* support it since the standard explicitly say the rtpmap
> > isn't required for static types, but there are some manufacturers who
> > ignored that part so there's the verbose_sdp=true compatibility option
> for
> > them.
>
>   I'm guessing you didn't read the post first :).  My questions here
> were somewhat rhetorical and certainly not posed by me (seeing as I go
> into the same kind of detail you have).  If you included it for list
> archival purposes, excellent!
>
> > That's not necessarily a given.
> >
> > In general though because the TCP connection explicitly signals the
> > connection closing the mapping will stay in the firewall. With UDP it is
> > removed after a long period of inactivity. That can cause problems with
> > signalling during a phone call unless the endpoints send keepalive
> packets
> > often enough.
> >
> > TLS will prevent the router helping with SIP ALG - you must have
> endpoints
> > capable of doing NAT traversal themselves (STUN). Though that's a good
> idea
> > in all cases anyway.
>
>   In my experience with a fairly large network and a number of
> endpoints TCP fragmentation is *much* more reliable than UDP
> fragmentation.  Various stateful firewalls also handle TCP much better
> (connection oriented and used by most applications people care about -
> more testing, etc).  Your points about keepalives and TLS are spot on
> although many devices don't have the "luxury" of keepalives due to
> issues with battery power.
>
> >> Maybe support deflate encoding?
> >
> >
> > That wouldn't automatically work. It would need support by both ends and
> > protocol changes to support it.
>
>   I'd hope by now you realize that I understand that - which is why
> I've raised this point simultaneously on the FreeSWITCH, Kamailio,
> Asterisk, and Wireshark mailing lists.  I'm hoping to builder broader
> support for these kinds of "standard" features within the open source
> ecosystem.
>
> --
> Kristian Kielhofner
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.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/20130920/a55c5384/attachment.html