> 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@kriskinc.com> wrote:
On Fri, Sep 20, 2013 at 9:49 AM, Steven Ayre <steveayre@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org