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?
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@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?
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@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@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?
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. söndagen den 25:e maj 2014 skrev Oleg Stolyar <olegstolyar@gmail.com>:
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@gmail.com<javascript:_e(%7B%7D,'cvml','olegstolyar@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@gmail.com<javascript:_e(%7B%7D,'cvml','olegstolyar@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?
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@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@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@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@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
-- Dušan Dragić
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@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@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@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@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@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
-- Dušan Dragić
_________________________________________________________________________ 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
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@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@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@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@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@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?
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@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@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@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.
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)
On 25 May 2014 08:41, Oleg Stolyar <olegstolyar@gmail.com> wrote: -
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@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@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@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
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@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@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@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@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@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@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@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@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
-- Kristian Kielhofner
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@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@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@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@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@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@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@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@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@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
-- Kristian Kielhofner
_________________________________________________________________________ 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
-- 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@conference.freeswitch.org ☎ +19193869900
participants (6)
-
Anthony Minessale
-
Dušan Dragić
-
Kristian Kielhofner
-
Michael Jerris
-
Oleg Stolyar
-
Peter Olsson