[Spce-user] UDP packet size

[Thomas Odorfer]

Hi,

The UDP fragmentation issue actually a familiar problem especially when
using clients supporting/providing a huge set of codecs and you or your
customers are behind private firewall/NAT routers.
It is quite unusual (however not impossible) that the Debian server with
sipwiseCE would cause this problem.
The problem is described quite well e.g. in the JITSI client FAQ
https://jitsi.org/Documentation/FAQ  ( §Why does my call stay in the
“Initiating Call” status and I can never connect? ).
The best way to avoid this issue with customers/users where you can’t
control client/network is to provide the appropriate settings for SIP
within your server DNS like SRV or NAPTR to motivate the clients to use
TCP/TLS instead UDP (some clients like Jitsi or Bria or others actually
use this).

Rgds
Thomas

Am 05.03.14 15:04 schrieb "Nikita Stashkov" unter <snl at sipmobile.org>:

>Ok, thank you.
>
>So, my diagnosis was correct - this is packet size.
>I tried on a public HotSpot, 3G connection - the same issue.
>So, can we make a conclusion that UDP is not recommended for home and
>public networks?
>
>Regards,
>Nikita Stashkov
>
>05 марта 2014 г., в 13:55, Andreas Granig <agranig at sipwise.com>
>написал(а):
>
>> Hi,
>> 
>> Please keep the list in CC for any non-privacy-critical things, we're
>> not doing private email support.
>> 
>> Alright, the second INVITE indeed exceeds typical MTU sizes (usually
>> 1400 byte, you're at 1540) according to your client log:
>> 
>> On 03/05/2014 01:42 PM, Nikita Stashkov wrote:
>>> channel [0x2d3d000]: message sent to [UDP://sipmobile.org:5060], size:
>>>[1540] bytes
>> 
>> Does this happen only on a particular network? If so, I guess you have a
>> faulty SoHo router/firewall, which drops the second part of the
>> fragmented UDP package of the INVITE message, so the Linux kernel on the
>> SPCE is unable to re-assemble the package.
>> 
>> If it happens anywere, then you should check your network in front of
>> your SPCE, maybe there is some kind of firewall or something.
>> 
>> I'm 100% sure it's a network issue, as it starts working if you remove
>> some codes, making the overall packet smaller (<1400 bytes) and it
>> doesn't get fragmented. I've seen this issue with dropped UDP fragments
>> a lot of times already, both in residential routers (wifi routers of
>> some sort) and in carrier grade firewalls.
>> 
>> Andreas
>