Summary

  • RFC 9993 specifies RTP packetisation, fragmentation, aggregation and SDP usage for MPEG-I haptic streams; it does not grant a received media unit authority to command an actuator.
  • Sender-supplied dependency, unit type and layer fields describe decoding and application-specific priority. They do not establish a safe intensity, a body location, user consent, device capability or a physical result.
  • A reliable deployment separates session acceptance, stream authentication, reassembly, decode, local safety policy, actuator command, sensor handling, emergency override and observed effect.

The phrase “high priority” is deceptively compact. In the RTP payload header described by RFC 9993, the MIHS Layer field can order units by the sender’s view of their importance to end-user experience. Zero is highest priority. The RFC also says that the semantics of individual layers are not specified: the application assigns them.

That design is correct for a transport format. It prevents a media header from pretending to know a receiver’s context. A value chosen by one haptic codec cannot know whether another receiver has a different actuator layout, a user-specific limit, a low battery condition, a local alarm, a damaged component or a policy that permits preview but not physical output. It is priority inside a sender’s media model, not an independent urgency classification.

RFC 9993 carries MPEG-I Haptic Stream units through RTP. A stream contains MIHS units, each with a header and zero or more packets. The standard defines single-unit, fragmentation and aggregation packet structures. It updates the haptics/hmpg registration from RFC 9695 and supplies SDP usage. These are important interoperability decisions. They say how a receiver can identify, negotiate, sequence and decode the representation. They do not make a representation a permitted experience.

Decodable is not renderable

The payload header’s D bit says whether a MIHS unit is dependent on earlier units. Independent units can be decoded independently and carry timing information; dependent units need earlier units. This is a decoder condition, not a safety claim. An independent vibration, force, pressure, position, velocity or temperature effect may be fully intelligible while still being locally inappropriate.

The same distinction applies to configuration. RFC 9993 offers optional SDP parameters for version, profile, level and related haptic coding capabilities, including defaults when parameters are absent unless an out-of-band agreement says otherwise. A completed offer/answer exchange can establish that two endpoints speak a compatible media language. It does not prove that either endpoint has agreed to a particular body mapping, maximum force, retention rule for sensor data or automatic actuation policy.

Nor does the RFC specify lip synchronisation between haptics and audio/video. An application may coordinate them, but a packet’s timestamp or a media session does not make a composite physical experience correct. The receiver must decide whether its clocks, state and local conditions permit rendering now, later, at a reduced level or not at all.

Fragmentation makes the operational gap especially clear. A fragmented MIHS unit must retain its payload header values across fragments; fragments are consecutive and ordered by RTP sequence number; nested fragmentation is prohibited. Yet RTP will usually not retransmit a missing fragment. A receiver may therefore have a syntactically valid first fragment, a declared unit type and a high layer value without a complete unit to decode. It must not treat partial arrival as a partial instruction to a motor or thermal actuator.

Loss handling needs an explicit product decision: drop the effect, wait within a bounded window, use an approved local fallback, fade an already running effect, or stop. The media RFC cannot choose among those consequences because they depend on the device, environment and user risk. An aggregation packet provides efficient transport, not permission to replay its effects after the moment for which they were intended has passed.

The physical world adds a separate safety authority

RFC 9993’s security considerations are unusually direct. Haptic sensors and actuators interact with the physical environment. Sensors can leak information. Tampered data can damage actuators. Misusing force, position, temperature, vibration, electrotactile functions, amplitude, frequency, keyframes or channel gain can harm a user. The RFC identifies the category of risk; it does not publish universal safe values or certify a receiver.

That leaves accountable choices where they belong. A local renderer needs a capability map, limits for each actuator and modality, policy for user state and environment, authenticated session context, rate and duration boundaries, an emergency stop that is outside the remote media path, and a record of every clamp, rejection and override. Encryption and integrity such as SRTP can protect a transport relationship. They do not prove that an otherwise authentic effect should be rendered.

The haptics media type and SDP registration are similarly narrow. IANA labels and parameter registries make shared interpretation possible. A label does not bind a device to act, make an output benign or disclose what a sensor has observed. Registry truth, negotiated session truth, packet truth, decoder truth, actuator truth and user outcome are different layers.

Heng Lu’s minimum-initial-specification principle describes the virtue of the RFC’s restraint. Common packet grammar can travel globally while rendering decisions remain local to the component that knows its physical limits. His running-code lens asks for the evidence that matters after receipt: which policy loaded, which limit applied, which actuator command was emitted, which sensor data was exposed and what actually happened.

RFC 9993 does not make haptics unsafe. It prevents transport compatibility from being confused with a safety or authority verdict.