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

[Mohit Dhiman]

Thanks Matt for the clarification.

Its kind of causing problem for me, the problem is not that big though.

I am really looking forward to work on this particular topic.

Thanks and Regards,
Mohit

On Fri, 19 Apr 2019, 7:53 pm Matt Fredrickson, <creslin at digium.com> wrote:

> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190420/c8eeaed1/attachment.html>