-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dtls-mtu param does not have any effect on RTPEngine #1806
Comments
Could be related to your OpenSSL version? |
hm, i got OpenSSL 1.1.1k on the server. When was this feature introduced ? |
I'm not sure about the specifics (but it does look like 1.1.1 should work), but it does depend on the build environment as well. If the package was built with an older version of OpenSSL then the feature won't work, even if the runtime version is newer. |
good point! i have built rpms on centos back in jul 2021 and i guess we didn't have 1.1.1 at that time :) Need to do non regression tests and finally test it in this specific scenario. |
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Unlike the previous code, this does not necessarily send DTLS from the same socket that received a message, nor to the same address that sent one, and instead always uses the selected_sfd and ->endpoint. This may or may not be a regression. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c (cherry picked from commit 0833216)
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Unlike the previous code, this does not necessarily send DTLS from the same socket that received a message, nor to the same address that sent one, and instead always uses the selected_sfd and ->endpoint. This may or may not be a regression. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c (cherry picked from commit 0833216)
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Unlike the previous code, this does not necessarily send DTLS from the same socket that received a message, nor to the same address that sent one, and instead always uses the selected_sfd and ->endpoint. This may or may not be a regression. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c (cherry picked from commit 0833216)
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Unlike the previous code, this does not necessarily send DTLS from the same socket that received a message, nor to the same address that sent one, and instead always uses the selected_sfd and ->endpoint. This may or may not be a regression. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c (cherry picked from commit 0833216) (cherry picked from commit 5331506)
Use a BIO WRITE callback instead of BIO_read'ing from the BIO after each operation. This is a more direct way to intercept data that needs to be sent out. Implement MTU-related BIO callbacks. Deduct the assumed IP MTU overhead from the configured MTU during startup. Unlike the previous code, this does not necessarily send DTLS from the same socket that received a message, nor to the same address that sent one, and instead always uses the selected_sfd and ->endpoint. This may or may not be a regression. Closes #1806 Change-Id: I4d4456df3f378d00782cbfa64afdb2a038217e6c (cherry picked from commit 0833216) (cherry picked from commit dd7e56d)
rtpengine version the issue has been seen with
Version: 9.5.1.1-1.el8
Used distribution and its version
Rocky linux 9
Linux kernel version used
4.18.0-372.32.1.el8_6.x86_64
CPU architecture issue was seen on (see
uname -m
)x86_64
Expected behaviour you didn't see
RTPEngine is returning a DTLS Server Hello packet that is 1397 bytes. When i set dtls-mtu to 1200 i should see DTLS Server Hello packet fragmented but this is not the case. RTPEngine still sends the same packet size.
while DTLS handshake works well in my pcap, on VPN network where the transport as a limited MTU (below 1350) we are unable to place calls.
Unexpected behaviour you saw
No response
Steps to reproduce the problem
in rtpengine.conf confiugure dtls-mtu = 1200 and restart.
place a WebRTC call and RTPEngine will respond with a DTLS Server Hello packet that is larger than what was configured.
Additional program output to the terminal or logs illustrating the issue
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: