Is there some sort of limit in my SIP rtpmap for codecs? I've got this list of codecs: <X-PRE-PROCESS cmd="set" data="global_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@20i,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@20i,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/> I'm seeing this output from tcpdump: v=0 o=FreeSWITCH 1395348540 1395348541 IN IP4 10.10.10.1 s=FreeSWITCH c=IN IP4 10.10.10.1 t=0 0 m=audio 25672 RTP/AVP 0 98 99 100 102 103 104 105 8 3 101 13 a=rtpmap:98 SPEEX/32000 a=rtpmap:99 SPEEX/16000 a=rtpmap:100 SPEEX/8000 a=rtpmap:102 iLBC/8000 a=fmtp:102 mode=30 a=rtpmap:103 G7221/32000 a=fmtp:103 bitrate=48000 a=rtpmap:104 G7221/16000 a=fmtp:104 bitr[|sip] Note the last line with bitr[|sip] where bitrate should be. This causes phones that would otherwise answer the call with the available codecs above to ignore and not ring at all.
Hi, Are you perhaps hitting the MTU limit? -- Keith Laaks -------------- On 2014/03/21, 6:06 AM, "Pete Ashdown" <pashdown@xmission.com> wrote:
Is there some sort of limit in my SIP rtpmap for codecs? I've got this list of codecs:
<X-PRE-PROCESS cmd="set" data="global_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@20i ,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@2 0i,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/>
I'm seeing this output from tcpdump:
v=0 o=FreeSWITCH 1395348540 1395348541 IN IP4 10.10.10.1 s=FreeSWITCH c=IN IP4 10.10.10.1 t=0 0 m=audio 25672 RTP/AVP 0 98 99 100 102 103 104 105 8 3 101 13 a=rtpmap:98 SPEEX/32000 a=rtpmap:99 SPEEX/16000 a=rtpmap:100 SPEEX/8000 a=rtpmap:102 iLBC/8000 a=fmtp:102 mode=30 a=rtpmap:103 G7221/32000 a=fmtp:103 bitrate=48000 a=rtpmap:104 G7221/16000 a=fmtp:104 bitr[|sip]
Note the last line with bitr[|sip] where bitrate should be. This causes phones that would otherwise answer the call with the available codecs above to ignore and not ring at all.
_________________________________________________________________________
Hi there, to be picky on terminology: UDP deals in packets. The underlying IP network deals in datagrams. NB: What follows is IPv4 stuff — if you’re using IPv6, fragmentation and reassembly isn’t done (or at least, not this way). Your initial mail suggested you’re using net 10 addresses (hence IPv4), so this should be all good: Normally, one UDP packet fits into one IP datagram. If it doesn’t, the sending host will split this into into a sequence of datagrams (also known as fragments), each of which will be sent separately across the network. The receiving host (i.e., the one with the IP address to which the UDP packet is sent) is responsible for sticking these fragments together to make one UDP packet, and for passing this to the listening application. I’d be willing to suspect that the full SIP/SDP message is passed in ->a<- UDP packet to the network stack at the sending host, and that stack will fragment it into several datagrams automatically if it’s too big to fit in one. fS doesn’t deal with datagrams (it’s an application using UDP packets). The receiving host network stack will pick up the datagram (or set of fragments) from the network, will stitch them together as needed, and the completed UDP packet will be passed up the stack, again automatically. The receiving fS/SIP server|client will receive that UDP packet and act on it. - BUT - Many routers/firewalls are severely brain damaged and drop subsequent fragments. They simply aren’t passed on to the destination host to reassemble. [I get this with DNS packets as well, so it’s not just SIP that gets b*gg*red]. I believe some folks (unwisely) set their host network stack to disable packet fragmentation and reassembly (which will mean the receiving host doesn’t even try to re-build packets — it just goes with the first [non-zero offset] datagram it receives). Hence the requests from others: Looking at a PCAP/Wireshark capture of the traffic “over the wire”, how big are the datagrams, is there more than one fragment (i.e., a datagram with a non-zero data offset), and does that “fit” with what you’re seeing at the receiving end? Also a question from me: Are there any intermediaries (firewall/NAT/routers/[VPN|V4-in-v6] tunnels) between the SIP source and destination? all the best, Lawrence On 21 Mar 2014, at 14:41, 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
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
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
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
Part two: as an entirely separate thing (must remember not to hit return too fast), RFC3261 says (in section 18.1.1) that one must switch to TCP if within 200 bytes of the discovered path MTU (or 1300 bytes if the path MTU is unknown). That's SIP actively trying to avoid fragments. However, the logic there is fairly old -- it kinda assumes that responses will never be more than 200 bytes larger than the original message, which is not the case for some IMS style stuff. SO .. . the problem is with SIP's choices on when to use UDP and when to use TCP, not with the underlying transport or network. 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
Thanks! On 03/21/2014 10:33 AM, Ken Rice 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?
Hello Pete, could you check the packet size while wiresharking the traffic? When a larger number of codecs is enabled, the SIP packet size can exceed the MTU size (~1500 bytes), so the single packet received is not complete. FS should send then 2 SIP UDP packets, but most SIP devices cannot assemble them. When possible, you may switch to TCP then when submitting theses large SIP packets. Freeswitch can handle this. /Peter On 03/21/14 05:06, Pete Ashdown wrote:
Is there some sort of limit in my SIP rtpmap for codecs? I've got this list of codecs:
<X-PRE-PROCESS cmd="set" data="global_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@20i,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=speex@32000h@20i,speex@16000h@20i,speex@8000h@20i,iLBC@30i,G7221@32000h,G7221@16000h,opus,PCMU,PCMA,GSM"/>
I'm seeing this output from tcpdump:
v=0 o=FreeSWITCH 1395348540 1395348541 IN IP4 10.10.10.1 s=FreeSWITCH c=IN IP4 10.10.10.1 t=0 0 m=audio 25672 RTP/AVP 0 98 99 100 102 103 104 105 8 3 101 13 a=rtpmap:98 SPEEX/32000 a=rtpmap:99 SPEEX/16000 a=rtpmap:100 SPEEX/8000 a=rtpmap:102 iLBC/8000 a=fmtp:102 mode=30 a=rtpmap:103 G7221/32000 a=fmtp:103 bitrate=48000 a=rtpmap:104 G7221/16000 a=fmtp:104 bitr[|sip]
Note the last line with bitr[|sip] where bitrate should be. This causes phones that would otherwise answer the call with the available codecs above to ignore and not ring at all.
_________________________________________________________________________ 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
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
participants (5)
-
Keith Laaks
-
Ken Rice
-
Lawrence Conroy
-
Pete Ashdown
-
Peter Steinbach