Xirsys.XTurn.Plugin.Allocation (xturn_plugin_api v0.1.1)

Allocation context built once per TURN allocation for plugin attach/init.

What problem this solves

When a client successfully Allocates on the TURN server, plugins decide whether to attach (attach?/2) and then initialize (init/2). This struct carries stable identity (5-tuple, relay address, username) without exposing the full server allocation GenServer state.

RFCs

RFC 5766 / RFC 8656 (Allocate)

Examples

iex> a = %Xirsys.XTurn.Plugin.Allocation{client_port: 54321, server_port: 3478}
iex> a.client_port
54321
iex> a.server_port
3478

Summary

Types

t()

Snapshot of a TURN allocation for plugin callbacks.

Types

t()

@type t() :: %Xirsys.XTurn.Plugin.Allocation{
  client_ip: :inet.ip_address() | nil,
  client_port: :inet.port_number() | nil,
  id: term(),
  ns: binary() | nil,
  owner_pid: pid() | nil,
  peer_id: binary() | nil,
  protocol: binary() | term() | nil,
  relay_address: {:inet.ip_address(), :inet.port_number()} | nil,
  server_ip: :inet.ip_address() | nil,
  server_port: :inet.port_number() | nil,
  started_at: term(),
  transport: term(),
  tuple5: term(),
  username: binary() | nil
}

Snapshot of a TURN allocation for plugin callbacks.

Fields

:id - opaque allocation id (often a binary), or nil
:tuple5 - client/server 5-tuple identifier used by the server, or nil
:client_ip - client IP tuple
:client_port - client port
:server_ip - server listen IP tuple
:server_port - server listen port
:protocol - requested transport bytes (for example UDP <<17,0,0,0>>)
:relay_address - {relay_ip, relay_port} advertised to the client
:transport - higher-level transport atom/tag when set by the server
:ns - optional namespace / tenant string
:peer_id - optional peer/session id string
:username - authenticated TURN username, or nil
:started_at - DateTime (or similar) when the allocation started
:owner_pid - allocation owner process pid, or nil