Allow per-user TURN relay allocation

[enobufs]

Summary

Current TURN server API allows us to customize how to allocate and create a net.PacketConn via ManagerConfig.AllocatePacketConn. This callback method however does not provide information of the TURN users for which the allocation was requested.

Motivation

TURN server is a middlebox where we could enforce policies such as how WebRTC traffic should be relayed. It could also be great place to run various diagnostic services. Allowing these services to be customizable per-user basis creates many business opportunities.

Describe alternatives you've considered

Per-process customization is possible but it is clunky and less flexible.

Additional context

classDiagram
    TURNServer --> UserManager: AuthHandler(username, realm)  
    TURNClient --> TURNServer: Allocate()  
    TURNServer --> RelayAddressGenerator: AllocatePacketConn(username)
    RelayAddressGenerator --> UserManager: LookupUser(username)

    namespace user_code {
        class UserManager {
        }
        class RelayAddressGenerator {
        }
    }
end

[rg0now]

Interesting issue, and thanks for the PR too. Can you please elaborate a bit? What is the simplest use case imaginable that would rely on this feature?

I'm not nitpicking, just trying to find the justification for introducing a breaking change.

[enobufs]

I use this feature in my project to use TURN server (pion/turn fork) as a network conditioner which is implemented inside the net.PacketConn AllocatePacketConn() returns. The associating a user with a specific allocation allows it to have different network settings (works as presets).

You can think of many applications:

• Rate limiter per user
• WebRTC traffic diagnostic service (the traffic is encrypted, but you can still tap into RTP/RTCP headers, STUN, etc)
• Selective QA/intergarion tests/troubleshooting system

[enobufs]

Once this feature lands, I'd be happy to add the TURN-based network conditioner to pion's offerings. I talked about this with @Sean-Der a while ago. FYI.

[oryjkov]

I just stumbled into wishing this feature existed. I'm trying to run a turn server locally to work around iOS blocking UDP connections from devices on its hotspot to the phone background.

Instead of trying to figure out the "public ip" - the ip that the turn server gets from the hotspot provider, which could change while the server is running, I wanted to pull it out from the original incoming connection (AuthHandler's source addr for example).

For now I'll just do something simple, like figure out the public address based on the SRC IP of the default route. But that could be a bit flaky.

[rg0now]

I'd also support this: being unaware of the user/realm on behalf of which an allocation is created is a huge limitation of the current API. Combined with https://github.com/pion/turn/pull/419, per-user relay address generators would allow to implement lots of useful features in the future.