Identity-Anchored Bearer Handover for Real-Time Media Sessions

Introduction Real-time media sessions break when the network bearer underneath them changes. A device that places a call on Wi-Fi and then leaves the coverage area moves to cellular; its IP address changes; the media stream, addressed to the old transport, stops. The signalling dialog may survive (if it rides a stable, address-independent control channel), yet audio is dead in one or both directions, and an in-dialog teardown sent over the now-defunct transport never arrives. The common mitigation is a central media relay (for example TURN ): both endpoints send media to a fixed rendezvous, so a change of local address is absorbed by the relay. This works, but it reintroduces a central dependency in the media path - a single operator-run waypoint that sees, and can interrupt, every call. For a decentralized, identity-first system that is precisely the property to avoid. This document takes a different anchor. The session is bound to a cryptographic identity and to the media-encryption key, not to the transport address. The transport is free to change; the key is the constant. On a bearer change the endpoint re-anchors the existing session onto the fresh transport over a stable control channel, and the encrypted media context continues. The maxim is: identity anchors, transport hops.

Problem Statement A correct handover mechanism must achieve all of the following at once:

Continuity: a live session survives a change of local transport address with at most a brief, bounded interruption.
No central media relay as a precondition: continuity MUST NOT require a third party in the media path.
No source-substitution attack: permitting the far end to relearn a media source MUST NOT let an off-path or on-path attacker hijack the stream by injecting from a new address.
Accountable transition: a handover SHOULD be expressible as an authenticated, auditable event rather than an unauthenticated "trust this new address".

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Identity anchor: The hardware-bound cryptographic identity (e.g. a JIS .aint with an Ed25519 key) to which a session is bound, independent of any transport address.
Bearer: The underlying network access path (Wi-Fi, cellular, Ethernet, tethered, etc.) over which transport packets travel.
Transport endpoint: The address/port currently used to carry signalling or media. An implementation detail, expected to change.
Control channel: A stable, address-independent, authenticated channel over which signalling and re-anchor requests travel; it survives a bearer change (for example an overlay that is reachable by name rather than by IP).
Media anchor: The default-routed party (typically the calling system's own media engine) that the moving endpoint re-points its media to; it is not a neutral third-party relay.
Re-anchor: The authenticated act of re-establishing an existing session's media path onto a fresh transport after a bearer change.

Model An identity-anchored session is described by three independent planes:

Identity plane: who the parties are. Proven per the identity system; the constant across the session.
Control plane: signalling and re-anchor requests, carried on the stable control channel; authenticated, address-independent.
Media plane: the real-time encrypted stream; its transport address is expendable and expected to change.

Continuity is the property that the identity and control planes persist across a media-plane transport change. The session key is shared in the identity/control plane and is not renegotiated on a mere transport change; only the transport binding is refreshed.

Handover Procedure When an endpoint in an active session detects that its default bearer or local transport address has changed, it performs the following:

Detect: the endpoint observes a new default network / local address (for example via an OS connectivity callback). Transient flaps SHOULD be debounced so a single switch yields a single re-anchor.
Re-anchor request: over the stable control channel, the endpoint sends an authenticated request to refresh the transport of the existing session (equivalent to a re-offer / ICE restart). The request is bound to the identity anchor, not to either transport address.
Transport refresh: the media anchor accepts the refreshed transport for the existing session and prepares to relearn the media source.
Resume: encrypted media flows over the new transport using the existing key context. The interruption SHOULD be bounded (an implementation target on the order of a few hundred milliseconds).

Because the dialog's transport is refreshed (not just a parallel re-registration), an in-dialog teardown after the change travels over the live transport and reaches the far end, avoiding stuck sessions.

Cryptographic Anchoring of Media Permitting the far end to relearn the media source from a new address (symmetric source latching) is unsafe over unauthenticated media: an attacker who can send packets from a new address could capture the stream. This document REQUIRES that media be encrypted and authenticated (for example SRTP or an equivalent AEAD media profile) for source relearning to be enabled. With authenticated media, source relearning is safe: a substituted or injected stream fails the media authentication and is discarded, while the legitimate endpoint - which holds the session key - continues to verify. The key, not the address, is therefore the anchor. The session key-exchange material travels in the control plane (carried inside the authenticated, address-independent control channel), so a bearer change does not require a new key exchange.

Signed Transport-Rebind Event A handover MAY be recorded as a signed control event so that the set of transport transitions for a session is auditable: who moved, between which bearer classes, at what point in the media sequence, signed by the moving device's identity key. Such events are an instance of a semantic surface manifest and MAY be sealed into a provenance trail . A non-normative shape: The signed event is a proof-plane artifact; it MUST NOT be required to carry media and MUST NOT gate the media handover itself. A failure to record the event MUST NOT interrupt the live session.

Deliberate Re-Anchor (Moving Target) The same authenticated re-anchor MAY be invoked deliberately rather than only in response to a bearer change. Because the key is the anchor, rotating the media transport mid-session presents a moving target: an observer has no fixed transport binding to lock onto. Each deliberate re-anchor incurs the same brief media interruption as a bearer-driven one; this is a defensive option, not a default behaviour, and its cadence is an implementation and policy choice.

Security Considerations Source-substitution (latching): as stated in -protected operation above, source relearning MUST be enabled only for authenticated media. Without media authentication, an endpoint MUST NOT relearn the media source from a new address mid-session. Re-anchor authentication: a re-anchor request MUST be authenticated to the session's identity anchor over the control channel; an unauthenticated "move my media to address X" is an obvious hijack primitive and MUST be rejected. A failed authentication SHOULD be treated as an offence, not as a retriable transient, so the mechanism cannot be abused as a denial of service. Privacy of transition metadata: a signed transport-rebind event reveals coarse bearer-class transitions (for example Wi-Fi to cellular). Such events SHOULD carry only bearer-class hints in any outward-visible surface and keep finer detail in the sealed manifest, consistent with . Relay avoidance: by not mandating a central media relay, this method removes a single interception/interruption point from the media path. When a relay is unavoidable (for example endpoints behind symmetric NAT with no reachable anchor), it is a last-resort fallback and SHOULD be authenticated to the same identity anchor.

IANA Considerations This document has no IANA actions.