Module stun 

A STUN Binding client, only as much of RFC 5389 as a keep-alive needs.

RFC 5626 §4.4.2 makes STUN the keep-alive for UDP flows: “All SIP UAs MUST support the STUN keep-alive technique for UDP flows.” It is a better keep-alive than a SIP request because the response carries the address the far end sees, so a UA learns that its NAT mapping changed rather than only that the flow still works — §4.4.2 has a changed XOR-MAPPED-ADDRESS mean the flow has failed.

Scope, deliberately: a Binding Request with no attributes, and a Binding Response read for its mapped address. No MESSAGE-INTEGRITY, no FINGERPRINT, no long-term credentials — §4.4.2’s keep-alive is unauthenticated, and RFC 5389 §10 does not require authentication for Binding over an established flow. Anything that needs the full protocol (ICE, RFC 8445) needs a different module, not more attributes bolted onto this one.

Enums

Reply

What a datagram that is STUN turned out to say.

Constants

HEADER_LEN

RFC 5389 §6: every STUN message begins with a 20-byte header.

MAGIC_COOKIE

RFC 5389 §6: the fixed cookie that distinguishes STUN from RFC 3489 and from other traffic.

Functions

binding_request

Encode a Binding Request with no attributes (RFC 5389 §6, §7.1).

is_stun

Whether a datagram is STUN rather than SIP (RFC 5389 §7.3).

new_transaction_id

A fresh transaction ID.

parse_reply

Read a STUN reply, or None if the datagram is not one.

Type Aliases

TransactionId

The 96 bits that tie a response to its request (RFC 5389 §6).