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