[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