Skip to content
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

Support SRTP #232

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Support SRTP #232

wants to merge 3 commits into from

Conversation

dennwc
Copy link
Contributor

@dennwc dennwc commented Nov 25, 2024

Supporting protocol PR:

TODOs:

  • Support media timeout.

@dennwc dennwc self-assigned this Nov 25, 2024
@dennwc dennwc force-pushed the srtp branch 2 times, most recently from 613c8fb to 8815495 Compare November 27, 2024 15:47
@dennwc dennwc marked this pull request as ready for review November 27, 2024 15:55
@dennwc dennwc requested a review from a team as a code owner November 27, 2024 15:55
Copy link
Contributor

@biglittlebigben biglittlebigben left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I just wonder about hardcoding the max packet size to 1500. It should be ok in most cases, but could load to hard to debug issues.

pkg/media/rtp/session.go Show resolved Hide resolved
pkg/sip/media_port.go Outdated Show resolved Hide resolved
@dennwc dennwc force-pushed the srtp branch 2 times, most recently from 6b62f0a to 3376c54 Compare December 9, 2024 17:11
if n > MTUSize {
if !overflow {
overflow = true
c.log.Errorw("RTP packet is larger than MTU limit", nil)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to alert on this? (sure sending invalid packet, potentially as an attempt to break our system)? If not, should this be a Warn or Info?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to not pass broken packet. Go crashes are fine and easy to recover from/fix, but crashes from C code are not. We could specifically fuzz the system to (hopefully) detect those.

As for the error/warn, even though this case won't break the system, it will still cause audio glitches in a specific call. I'd like to know when it happens, especially when a fix is as easy as increasing the buffer size. So I'd like to keep it as an error here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants