While I appreciate what you are saying is how things are supposed to work, but many of us can tell you its doesn't necessarily work that way in the real world... And yes people are still using that early code, and they are still using broken routers and ip stacks all over the place... Its not unusual to walk into a reputable colo facility these days and still see equipment in production that cost more in power then it does to just replace the things already. Its also not unusual to wander in and see things like Juniper M5 or M10s that have long been "end of support" (forget talking about end of life lol) On 3/21/14 10:52 AM, "Lawrence Conroy" <lconroy@insensate.co.uk> wrote:
Hi Ken, folks, Um ... strictly true but **VERY** misleading. UDP doesn't handle fragmentation only because it's done at the IP layer -- see the inside front cover of Stevens' TCP/IP Illustrated Volume 1. You can send a UDP packet out of up to 64 KBytes. If you do, it'll be fragmented by the IP layer into a set of fragments, each datagram being less than the MTU, with the fragment offset in all but the first datagram being non-zero.
I send and receive DNS packets of up to 3-4 KBytes [with the EDNS0 bufsize option set :] -- problems only occur with brain-damaged DNS servers (Microsoft) and intrusively dumb home router/NATs.
----
TCP was originally added as an option for SIP leading up to RFC2543 because some people didn't like the message retransmission timers -- back then, the idea was that if one had a TCP stream set up, one didn't need to do the retransmit logic in SIP. I agree that it was also added as an option because some ancient host network stacks were broken (and didn't handle fragmentation and reassembly). N[and some early SIP implementations had hard limits in their application buffers -- no one would ever need more than a kilobyte for a SIP message, would they?]. Now the network stacks do support F&R, and I sincerely hope no-one's still trying to use that early C*s*o SIP code.
all the best, Lawrence
On 21 Mar 2014, at 16:33, Ken Rice <krice@freeswitch.org> wrote:
UDP doesn't handle fragmentation... This is why sip is required to use both UDP and TCP (if you exceed MTU you Must use TCP per the RFC)
There are things like compressed headers to help with this but that only goes so far when you have 1500+ bytes in the SDP alone...
On 3/21/14 8:41 AM, "Pete Ashdown" <pashdown@xmission.com> wrote:
On 03/21/2014 03:32 AM, Keith Laaks wrote:
Hi,
Are you perhaps hitting the MTU limit?
Are SIP transmissions limited to a single packet confined by MTU? Why not just continue the list in the next packet?
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH
_________________________________________________________________________ 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
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH