-
Notifications
You must be signed in to change notification settings - Fork 168
Avoid unnecessary turn address resolution in the turn client #773
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
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #773 +/- ##
==========================================
- Coverage 78.84% 78.83% -0.02%
==========================================
Files 41 41
Lines 5441 5452 +11
==========================================
+ Hits 4290 4298 +8
- Misses 921 923 +2
- Partials 230 231 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@@ -721,6 +723,11 @@ func (a *Agent) gatherCandidatesRelay(ctx context.Context, urls []*stun.URI) { | |||
} | |||
locConn = turn.NewSTUNConn(conn) | |||
|
|||
// We don't need to resolve address of the turn server, since we are using | |||
// proxy dialer. | |||
if _, err = a.net.ResolveUDPAddr("udp4", turnServerAddr); err != 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.
Why can't we always omit the TURN Server Addr now?
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.
In the proxy case, the TURN address is only used only for debug logging. So maybe completely skipping it is too much? Some might find having the address in the logs useful for debugging. What do you think?
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 you think it would be possible to make this happen internally in the TURN package? Otherwise every user of the package has to do this check.
I think we should remove it personally. It confused me, and I imagine people in the future won't understand the purpose (and delete or modify)
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.
The only viable approach I can see on the turn library side is to add IgnoreTURNResolveError
flag to this configuration struct: https://github.com/pion/turn/blob/master/client.go#L39
And it breaks the minimalism of the config, unfortunately :(
@amanakin I released a new version of |
Description
The
turn.NewClient
function in the library currently requires TURN server addresses passed to it to be resolvable. This causes an error when using a proxy, as the TURN address might only be resolvable by the proxy server itself, not by the client application initiating the connection.To avoid this error in proxy scenarios, this PR modifies the initialization to omit the TURN address when creating the
turn.Client
.Blocker:
This change depends on functionality introduced in
pion/turn
Pull Request #450.