[asterisk-dev] No MTU discovery and packet sizing in DTLS implementation by RTP engine (res_rtp_asterisk) which leads to IP fragmentation
mohitdhiman736 at gmail.com
Sat Apr 20 05:07:45 CDT 2019
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,
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>
> > 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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-dev