[asterisk-dev] No MTU discovery and packet sizing in DTLS implementation by RTP engine (res_rtp_asterisk) which leads to IP fragmentation

Matt Fredrickson creslin at digium.com
Fri Apr 19 09:22:52 CDT 2019


On Fri, Apr 19, 2019 at 5:29 AM Mohit Dhiman <mohitdhiman736 at gmail.com> wrote:
>
> As per the RFC 4347 section-4.1.1
>
>    Each DTLS record MUST fit within a single datagram.  In order to
>    avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine
>    the MTU and send records smaller than the MTU.  DTLS implementations
>    SHOULD provide a way for applications to determine the value of the
>    PMTU (or, alternately, the maximum application datagram size, which
>    is the PMTU minus the DTLS per-record overhead).  If the application
>    attempts to send a record larger than the MTU, the DTLS
>    implementation SHOULD generate an error, thus avoiding sending a
>    packet which will be fragmented.
>
> But i think that res_rtp_asterisk's implementation of DTLS does not ensures the DTLS record size to be less than MTU
> and because of this i am getting IP fragmentation of DTLS packets which is causing problems with certain ISPs while using WebRTC.
>
> can someone please confirm this, and if it is true that asterisk's RTP engine does not ensure application layer fragmentation of DTLS
> then is there some specific reason behind this implementation?

We looked into this a while ago, and as I recall, the SSL library
didn't have a good way of doing fragmentation internally so that would
require us at an application layer to fragment DTLS packets properly.
It seemed like it was going to be quite a bit of work at the time and
the current implementation works for a lot of people.  More
importantly though, nobody else has taken on the task to improve it,
so thus, it does not exist yet :-)

The path MTU detection was another dimension to this that needed to be
worked on as well.

-- 
Matthew Fredrickson
Digium - A Sangoma Company | Asterisk Project Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA



More information about the asterisk-dev mailing list