[Freeswitch-users] Fragmented IP protocol Issue with latest master and 1.4.4

Tue May 27 19:51:23 MSD 2014

TCP is the best bet,

However, you can also set the variable verbose_sdp=false globally or per
call leg to get rid of redundant a= lines for well-known codecs and reduce
the sdp a little more.  Also if you know what codec is going to be used
just limit the codec to that one with absolute_codec_string set in the {}
vars.

On Tue, May 27, 2014 at 10:19 AM, Kristian Kielhofner <kris at kriskinc.com>wrote:

> That may very will only make your problems worse.
>
> 9000 bytes is the max MTU for jumbo frames on Gigabit ethernet. That
> will cover Amazon's internal network but will only increase the amount
> of fragmentation that will occur once you hit the Internet (typically
> 1500 bytes AT BEST). With the state of IP+UDP fragmentation and path
> MTU discovery on the internet Mike's position is the correct one.
> Squeeze what you can out of UDP with what tricks you can but switching
> to TCP transport is your best bet. Most of this is covered in my blog
> post here (scroll towards the bottom):
>
> http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html
>
> On Tue, May 27, 2014 at 10:39 AM, Oleg Stolyar <olegstolyar at gmail.com>
> wrote:
> > Turns out that AWS changed the MTU on the new instance types to 9000.
>  They
> > are still investigating the various issues this is causing but I will
> just
> > stay on the more stable instance types for now.  Otherwise, I was all
> ready
> > to switch to TCP.
> >
> >
> > On Tue, May 27, 2014 at 6:38 AM, Michael Jerris <mike at jerris.com> wrote:
> >>
> >> If you are very close to the limit on fragments and just want to punt on
> >> the problem, you can use compressed headers to squeeze a bit more out,
> in
> >> the end, trying to fight udp fragmentation is a loosing battle at least
> on
> >> the internet, and switching to tcp is usually the best solution that I
> see
> >> always works.  You can also reduce the cdoecs passed along to help
> shrink
> >> packets a bit.
> >>
> >> Mike
> >>
> >> On May 25, 2014, at 3:05 PM, Oleg Stolyar <olegstolyar at gmail.com>
> wrote:
> >>
> >> Thanks guys, I am feeling silly but hopefully this will help someone
> else
> >> who runs into this issue.
> >>
> >> After you confirmed that fragmentation happens in the OS, I
> >> realized/remembered that there is one more difference between the
> servers
> >> with the old and new FreeSWITCH.  They are both AWS instances and they
> are
> >> both CentOS 5.9 and based on the same image but different instance
> types.
> >> So, it looks like the difference is that m3.xlarge instances work fine
> but a
> >> little cheaper c3.xlarge have this issue.
> >>
> >>
> >> On Sun, May 25, 2014 at 3:37 AM, Dušan Dragić <dragic.dusan at gmail.com>
> >> wrote:
> >>>
> >>> As Peter said, look at the contents of your SIP messages, including
> >>> SDP, find what changed. It's not freeswitch fragmenting the ip
> >>> datagrams, it's the OS (and/or routers).
> >>> As for thing to try, slim down SDP by removing some unneeded codecs ,
> >>> enable compact headers in the profile etc.
> >>>
> >>> Search the mailing list... there have been a few fragmentation
> >>> discussions.
> >>>
> >>> On 25 May 2014 08:41, Oleg Stolyar <olegstolyar at gmail.com> wrote:
> >>> > More tests showed that what makes the difference is the size of the
> SIP
> >>> > message FreeSWITCH returns.  If the message is 1472 bytes or less, it
> >>> > works,
> >>> > more than that - it does not.  1472 + 20 (IPv4 header) + 8 (UDP
> header)
> >>> > -
> >>> > 1500 which is the standard MTU size on Ethernet.
> >>> >
> >>> > It seems that the new master is not properly fragmenting messages, so
> >>> > that
> >>> > everything after the first 1500 bytes is lost.  Again - the old
> >>> > FreeSWITCH
> >>> > did it just fine.
> >>> >
> >>> > Should I file a JIRA bug for this?  Or is this a known issue?
> >>> >
> >>> >
> >>> >
> >>> > On Sat, May 24, 2014 at 11:50 AM, Oleg Stolyar <
> olegstolyar at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Now I am thinking that the Fragmented IP may be a red herring since
> n
> >>> >> the
> >>> >> old version it's also happening but only once.  Then the softphone
> >>> >> acknowledges it and that's the end of it.  Something in the OK
> message
> >>> >> from
> >>> >> the current master prevents the softphone from acknowledging the OK
> >>> >> message.
> >>> >> I could not find significant differences in the OK message with the
> >>> >> old
> >>> >> version that works.  The only difference seems to be Min-SE: 120
> >>> >> header in
> >>> >> the old version which is missing from the new one.
> >>> >>
> >>> >> This is happening with at least two completely different softphone,
> so
> >>> >> I
> >>> >> can't blame the phones :-)  It's 100% reproducible.
> >>> >>
> >>> >> What else can I do to debug this?
> >>> >>
> >>> >> Any help would be greatly appreciated!
> >>> >>
> >>> >>
> >>> >> On Fri, May 23, 2014 at 10:10 PM, Oleg Stolyar <
> olegstolyar at gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> Hi guys,
> >>> >>>
> >>> >>> I upgraded to the master (and it's also happening in 1.4.4).  I
> have
> >>> >>> some
> >>> >>> very long SIP addresses in my messages.  It used to work fine on
> the
> >>> >>> master
> >>> >>> from August 2013.  However, now when FS sends back the OK message,
> to
> >>> >>> invites with very long destination numbers, the originator
> softphone
> >>> >>> cannot
> >>> >>> receive it.  This is only happening with UDP.  TCP works fine.
> >>> >>>
> >>> >>> Here is a snapshot of wireshark for the master
> >>> >>> https://www.dropbox.com/s/0y0m4f4t4cgnwu0/Current%20Master.PNG
> >>> >>>
> >>> >>> And here is the snapshot of the same OK messages for the August
> 2013
> >>> >>> FS
> >>> >>> that works
> >>> >>>
> https://www.dropbox.com/s/7wpsyw4r2skifpb/August%202013%20Version.PNG
> >>> >>>
> >>> >>> Any ideas how to fix this?  Is this a known issue?
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>
> >>
> >>
> _________________________________________________________________________
> >> 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
> >>
> >
> >
> > _________________________________________________________________________
> > 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
> >
>
>
>
> --
> 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
>

-- 
Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬

☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞
http://twitter.com/FreeSWITCH
☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
<http://freeswitch.org/g+>*

ClueCon Weekly Development Call
☎ sip:888 at conference.freeswitch.org  ☎ +19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140527/c340d7af/attachment.html 