It's not up to FS to fragment the packets, it's your OS. Try to find out what differs in the headers between the versions, and see if it's maybe possible to tweak some data away (by a setting), or maybe try to use compressed headers.<br>
<br>söndagen den 25:e maj 2014 skrev Oleg Stolyar <<a href="mailto:olegstolyar@gmail.com">olegstolyar@gmail.com</a>>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<div>
<br></div><div>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.</div><div><br></div><div>Should I file a JIRA bug for this? Or is this a known issue?</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 24, 2014 at 11:50 AM, Oleg Stolyar <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','olegstolyar@gmail.com');" target="_blank">olegstolyar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <b>Min-SE: 120</b> header in the old version which is missing from the new one. <div>
<br></div><div>This is happening with at least two completely different softphone, so I can't blame the phones :-) It's 100% reproducible.</div><div><br></div><div>What else can I do to debug this?</div><div><br>
</div><div>Any help would be greatly appreciated!</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 10:10 PM, Oleg Stolyar <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','olegstolyar@gmail.com');" target="_blank">olegstolyar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys,<div><br></div><div>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.</div>
<div><br></div><div>Here is a snapshot of wireshark for the master</div><div><a href="https://www.dropbox.com/s/0y0m4f4t4cgnwu0/Current%20Master.PNG" target="_blank">https://www.dropbox.com/s/0y0m4f4t4cgnwu0/Current%20Master.PNG</a><br>
</div>
<div><br></div><div>And here is the snapshot of the same OK messages for the August 2013 FS that works</div><div><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>
</div><div><br></div><div>Any ideas how to fix this? Is this a known issue?</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote>