<p></p>
<h3 dir="auto">Description</h3>
<p dir="auto">Larger SIP frames get dropped when sent over UDP and IPv6.  The sending side has MTU 1500 and the receiving side has MTU 1492.  This is an IPv6-only setup, so this is problematic.  Also, pulling down the MTU of a general server for a tunneled peer would smear like an oil stain.  The suggestion to fallback on TCP feels like a hack.</p>
<h3 dir="auto">Troubleshooting</h3>
<h4 dir="auto">Reproduction</h4>
<p dir="auto">Send a SIP message to a network interface with a lower MTU than the submitted frame size.</p>
<h4 dir="auto">Debugging Data</h4>
<p dir="auto">None, transmission works fine.</p>
<h4 dir="auto">Log Messages</h4>
<p dir="auto">None, transmission works fine.</p>
<h4 dir="auto">SIP Traffic</h4>
<p dir="auto">Irrelevant.</p>
<h4 dir="auto">Code Investigation</h4>
<p dir="auto">I explored the Kamailio source code for MTU handling.</p>
<p dir="auto"><a href="https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a98f0a64/src/core/udp_server.c#L340-L349">https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a98f0a64/src/core/udp_server.c#L340-L349</a></p>
<ul dir="auto">
<li>This defaults to switching off the Don't Fragment bit on IPv4 frames, to allow them to be broken up downstream.</li>
<li>This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value <code class="notranslate">IPV6_MTU_DISCOVER</code></li>
<li>Note that IPv6 is never broken up by routers; they always return ICMPv6 message Packet Too Big</li>
<li>Note that IPv6 Path MTU discovery by the kernel is automatic only for connected UDP sockets</li>
<li>Since Kamailio uses unconnected UDP sockets, Path MTU issues cause packets to be dropped</li>
<li>Note that such packet drops depend on a somewhat dynamic SIP message size, causing random behaviour</li>
<li>I therefore suggest that Kamailio is lacking in some of its IPv6 logic</li>
</ul>
<p dir="auto"><a href="https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a98f0a64/src/core/udp_server.c#L331-L339">https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a98f0a64/src/core/udp_server.c#L331-L339</a></p>
<ul dir="auto">
<li>This enables the reporting of ICMP errors, including Path MTU but also other useful things like Host Not Found</li>
<li>This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value <code class="notranslate">IPV6_RECVERR</code></li>
<li>Note that the same behaviour is available on BSD, so it need not be specific to Linux</li>
<li>Note that handling errors is done with <code class="notranslate">recvmsg()</code> with a flag <code class="notranslate">MSG_ERRQUEUE</code>, which is not used in Kamailio</li>
<li>Note that the ancillary data from <code class="notranslate">recvmsg()</code> holds data to cleverly handle ICMP or ICMPv6 responses</li>
<li>I therefore suggest that Kamailio is lacking a fair chunk of its ICMP and ICMPv6 logic</li>
<li>I expect that this may bring efficiency gains due to faster closing of transactions</li>
</ul>
<h3 dir="auto">Possible Solutions</h3>
<p dir="auto">I have been thinking about ways to lower MTU values only for some peers.</p>
<ol dir="auto">
<li>
<p dir="auto">Using connected sockets might work, possibly as an alternative when Path MTU problems arise.  It might not scale however.</p>
</li>
<li>
<p dir="auto">Every socket could have an extra sending socket set to a lower MTU.  The use of <code class="notranslate">SO_REUSEADDR</code> seems to allow for that.</p>
</li>
<li>
<p dir="auto">Before falling back on an extra socket, the desired MTU could be set.  Alternatively, as for IPv6, an MTU of 1280 might be considered in  many cases:</p>
<ul dir="auto">
<li><em>If you can carry 6 out of 8 coffee mugs from the kitchen, you need to walk twice, and 4+4 is easier than 6+2</em></li>
<li>Anything over the MTU splits into at least 2 frames</li>
<li>The headers added are 40 bytes IPv6 header and 8 bytes Fragment Extension Header</li>
<li>2 frames can hold a single frame of 2*1280-40-8 = 2512 bytes</li>
<li>Up to 2512 bytes original MTU, breakup in 1280 byte frames will be fine</li>
<li>3 frames are going to be useful for larger frames, then a similar style can be used</li>
<li>This might help to decide whether 1280 or a higher MTU is most desirable</li>
</ul>
</li>
</ol>
<h3 dir="auto">Additional Information</h3>
<pre class="notranslate"><code class="notranslate">Kamailio 5.2.1 from Debian stable
</code></pre>
<ul dir="auto">
<li><strong>Operating System</strong>:</li>
</ul>
<pre class="notranslate"><code class="notranslate">Linux Debian stable on kernel 4.19.0
</code></pre>
<p dir="auto">(I don't suppose it matters, this code has been around for ages.  I used permalinks for stable reference).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/3119">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABO7UZKN4ZCY4VIM5QVJZATVK5A4VANCNFSM5WOTUNDA">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/ABO7UZJ4G5OVCK3Y3FG6CVTVK5A4VA5CNFSM5WOTUNDKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4SQTH7AA.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><kamailio/kamailio/issues/3119</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/kamailio/kamailio/issues/3119",
"url": "https://github.com/kamailio/kamailio/issues/3119",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>