-
Notifications
You must be signed in to change notification settings - Fork 31
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
base: main
Are you sure you want to change the base?
Support SRTP #232
Conversation
613c8fb
to
8815495
Compare
There was a problem hiding this 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.
6b62f0a
to
3376c54
Compare
if n > MTUSize { | ||
if !overflow { | ||
overflow = true | ||
c.log.Errorw("RTP packet is larger than MTU limit", nil) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Supporting protocol PR:
TODOs: