---
title: "RTP RTP Payload Format for Haptics" Haptics
abbrev: RTP-Payload-Haptic RTP Payload Format for Haptics
docname: draft-ietf-avtcore-rtp-haptics-latest
number: 9993
date: {DATE}
stream: 2026-05
submissiontype: IETF
category: std
consensus: true
ipr: trust200902
area: Transport WIT
workgroup: avtcore
updates: 9695
stand_alone: yes
obsoletes:
v: 3
lang: en
pi: [toc, sortrefs, symrefs, docmapping] symrefs]
keyword:

author:
  -
    ins: HS. Yang
    name: Hyunsik Yang
    org: InterDigital
    email: hyunsik.yang@interdigital.com
    country: USA United States of America
  -
    ins: X. de Foy
    name: Xavier de Foy
    org: InterDigital
    email: xavier.defoy@interdigital.com
    country: Canada

normative:
  ISO.IEC.23090-31:
    title: "Information technology - Coded representation of immersive media" media - Part 31: Haptics coding"
    author:
      org: "ISO/IEC"
    date: 2025
    seriesinfo:
      ISO/IEC: 23090-31:2025
    target: https://www.iso.org/standard/86122.html

  RFC2119:
  RFC8174:
  RFC3550:
  RFC9695:
  RFC8866:
  RFC3264:

informative:
  RFC2736:
  RFC8088:
  RFC7201:
  RFC7202:
  RFC7296:
  RFC4303:
  RFC9325:
  RFC5124:
  RFC3711:
  RFC3551:
  RFC4585:
  RFC5104:

--- abstract

<!--[rfced] FYI: We updated the short title that spans the header of
the PDF file as shown below (full title fits the space).

Original:
   RTP-Payload-Haptic

Current:
   RTP Payload Format for Haptics
-->

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

This memo specifies an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS MPEG-I Haptic Stream (MIHS) units including a MIHS (MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for haptics/hmpg, registered with IANA in RFC9695, 'haptics/hmpg' (RFC 9695) did not include any required or optional parameters. This memo updates RFC9695 RFC 9695 and the haptics/hmpg 'haptics/hmpg' registration to add optional parameters. It also provides SDP Session Description Protocol (SDP) usage information for the haptics 'haptics' media type.

--- middle

# Introduction

Haptics provides users with tactile effects in addition to audio and video, allowing them to experience sensory immersion. Haptic data is mainly transmitted to devices that act as actuators and provides actuators, providing them with information to operate according to the values defined in haptic effects. The IETF registered haptics 'haptics' as a primary media type type, akin to audio 'audio' and video [RFC9695]. 'video' {{RFC9695}}.

The MPEG Haptics Coding standard [ISO.IEC.23090-31] {{ISO.IEC.23090-31}} defines the data formats, metadata, and codec architecture to encode, decode, synthesize synthesize, and transmit haptic signals. Within this MPEG standard, a haptic media stream is composed of MIHS units including a MIHS unit header and zero or more MIHS packets. The MIHS unit is a unit of packetization suitable for streaming, streaming and is similar in essence to the NAL (Network Network Abstraction Layer) Layer (NAL) unit defined in some video specifications. This document specifies how haptic data (MIHS units) can be transmitted using the RTP protocol. This document follows recommendations in [RFC8088] {{RFC8088}} and [RFC2736] {{RFC2736}} for RTP payload format writers. This document does not specify synchronization (lip sync) mechanisms between haptics and audio/video components.  In addition, this document specifies the associated SDP parameters and SDP Offer/Answer offer/answer considerations for the haptics 'haptics' media type.

# Conventions

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

{::boilerplate bcp14-tagged}

# Definition Definitions

This document uses the definitions of the MPEG Haptics Coding standard {{ISO.IEC.23090-31}}. Some of these terms are provided here for convenience.

Actuator: component
: Component of a device for rendering haptic sensations.

Avatar: body
: Body (or part of body) representation.

Band: component
: Component in a channel for containing effects for a specific range of frequencies.

Channel: component
: Component in a perception containing one or more bands rendered on a device at a specific body location.

Device: physical
: Physical system having one or more actuators configured to render a haptic sensation corresponding with a given signal.

Effect: component
: Component of a band for defining a signal, consisting of a haptic waveform or one or more haptic keyframes.

Experience: top level
: Top-level haptic component containing perceptions and metadata.

Haptics: tactile
: Tactile sensations.

Keyframe: component
: Component of an effect mapping a position in time or space to an effect parameter such as amplitude or frequency.

Metadata: global
: Global information about an experience, perception, channel, or band.

MIHS unit: unit
: Unit of packetization of the MPEG-I Haptic Stream format, which is used as unit of payload in the format described in this memo. See {{haptic-format-description}} for details.

Modality: type
: Type of haptics, such as vibration, force, pressure, position, velocity, or temperature.

Perception: haptic
: Haptic perception containing channels of a specific modality.

Signal: representation
: Representation of the haptics associated with a specific modality to be rendered on a device.

Hmpg format: hmpg is a
: A binary compressed format for haptics data. Information is stored in a binary form form, and data compression is applied on data at the band level. The haptics/hmpg 'haptics/hmpg' media subtype is registered in {{RFC9695}} and updated by this memo.

Independent unit: a
: A MIHS unit is independent if it can be decoded independently from earlier units. Independent units contain timing information and are also called "sync units" in {{ISO.IEC.23090-31}}.

Dependent unit: a
: A MIHS unit is dependent if it requires earlier units for decoding. Dependent units do not contain timing information and are also called "non-sync units" in {{ISO.IEC.23090-31}}.

Time-independent effect: a
: A haptic effect that occurs regardless of time. The tactile feedback of a texture is a representative example. Time-independent effects are encoded in spatial MIHS units, as defined in {{MIHS-format}}.

Time-dependent effect: a
: A haptic effect that varies over time. For example, tactile feedback for vibration and force are time-dependent effects, effects and are encoded in temporal MIHS units, as defined in {{MIHS-format}}.

# Haptic Format Description {#haptic-format-description}

## Overview of Haptic Coding

The MPEG Haptics Coding standard specifies methods for efficient transmission and the rendering of haptic signals, to enable immersive experiences. It supports multiple types of perceptions, including the most common vibrotactile (sense of touch that perceives vibrations) and kinesthetic perceptions (tactile resistance or force), but and also other, other less common perceptions, including for example such as the sense of temperature or texture. texture, for example. It also supports two approaches for encoding haptic signals: a "quantized" approach based on samples of measured data, data and a "descriptive" approach where the signal is synthesized using a combination of functions. Both quantized and descriptive data can be encoded in a text-based exchange format based on JSON (.hjif), (.hjif) or in a binary packetized format for distribution and streaming (.hmpg). This last format is referred to as the MIHS format and is a base for the RTP payload format described in this document.

## MIHS format Format {#MIHS-format}

MIHS is a stream format used to transport haptic data. Haptic data data, including haptic effects effects, is packetized according to the MIHS format, format and delivered to actuators, which operate according to the provided effects. The MIHS format has two levels of packetization, packetization: MIHS units and MIHS packets.

MIHS units are composed of a MIHS unit header and zero or more MIHS packets. Four types of MIHS units are defined. An initialization MIHS unit contains MIHS packets carrying metadata necessary to reset and initialize a haptic decoder, including a timestamp. A temporal MIHS unit contains one or more MIHS packets defining time-dependent effects and providing provides modalities such as pressure, velocity, and acceleration. The duration of a temporal unit is a positive number. A spatial MIHS unit contains one or more MIHS packets providing time-independent effects, such as vibrotactile texture, stiffness, and friction. The duration of a spatial unit is always zero.
A silent MIHS unit indicates that there is no effect during a time interval interval, and its duration is a positive number.

A MIHS unit can be marked as independent or dependent. When a decoder processes an independent unit, it resets the previous effects and therefore provides a haptic experience independent from any previous MIHS unit.  A dependent unit is the continuation of previous MIHS units and cannot be independently decoded and rendered without having decoded a previous MIHS unit(s). Initialization and spatial MIHS units are always independent units. Temporal and silent MIHS units can be dependent or independent units.

<!--[rfced] FYI: In Figure 1, we adjusted the spacing of the middle
box to include "Temporal Unit" on one line. Please let us know of
any objections.
-->

{{figure-stream}} illustrates a succession of MIHS units in a MIHS stream.

~~~~~~~~~~ aasvg
+--------+ +-------+ +------------+ +-------------+ +-------------+ +-----------+
|Initial*| |Spatial| |  Temporal  | |Temporal Unit| |Temporal Unit| |Silent Unit|
| Unit   |-| Unit  |-|Unit(indep.)|-|  |-|   (indep.)  |-| (dependent) |-| (indep.)  |
+--------+ +-------+ +------------+ +-------------+ +-------------+ +-----------+
 *Initialization
~~~~~~~~~~
{: #figure-stream title="Example of MIHS stream"} Stream"}

# Payload Format For for Haptics

## RTP Header Usage {#rtp-usage}

The RTP header is defined in {{RFC3550}} and represented in {{figure-rtpheader}}. Unless contextualized below, the meaning of the fields depicted in  {{figure-rtpheader}} is the same as in {{rtp-usage}} {{Section 5.1 of {{RFC3550}}. RFC3550}}.

<!--[rfced] In Figure 2, should "(TS)" be added after "Timestamp" to
correspond with the entry for timestamp and for consistency with the
two terms that appear below it in the figure?

Original:
   Timestamp

Perhaps:
   Timestamp (TS)
-->

~~~~~~~~~~ aasvg
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+---------------------------------------------------------------+
|           Synchronization Source (SSRC) Identifier            |
+---------------------------------------------------------------+
|            Contributing Source (CSRC) Identifiers             |
|                             ....                              |
+---------------------------------------------------------------+
~~~~~~~~~~
{: #figure-rtpheader title="RTP header Header for Haptic."} Haptic"}

<!--[rfced] We note different list styles in Sections 5.1, 5.2, and
5.3.2. May we make these lists consistent by using the format shown
below?  (See the text for more examples.)

Original:
 (Section 5.1)
    Marker bit (M): 1 bit. The marker bit ...
    Timestamp (TS): 32 bits. A timestamp ...

 (Section 5.2)
    D (Dependency, 1 bit): This field indicates ...
    UT (Unit Type, 3 bits): This field indicates ...

Perhaps:
 (Section 5.1)
    M (Marker bit): 1 bit. The marker bit ...
    TS (Timestamp): 32 bits. A timestamp ...

 (Section 5.2)
    D (Dependency): 1 bit. This field indicates ...
    UT (Unit Type): 3 bits. This field indicates ...
-->

Marker bit (M):
: 1 bit. The marker bit SHOULD be set to one in the first non-silent RTP packet after a period of haptic silence. This enables jitter buffer adaptation and haptics device washout (i.e., reset to a neutral position) prior to the beginning of the burst with minimal impact on the quality of experience for the end user. The marker bit in all other packets MUST be set to zero.

Timestamp (TS):
: 32 bits. A timestamp representing the sampling time of the first sample of the MIHS unit in the RTP payload. The clock frequency MUST be set to the sample rate of the encoded haptic data and is conveyed out-of-band out of band (e.g., as an SDP parameter).

## Payload Header {#payload-header}

<!--[rfced] We note two uppercase forms of "Haptic" in Sections 5.2 and
5.4. Are these correct as is, or should they be made lowercase for
consistency?

Current:
   The RTP payload header follows the RTP header.  Figure 3 describes
   the RTP payload header for Haptic.

   In some multimedia conference scenarios using an RTP video mixer
   (e.g., when adding or selecting a new source), it is recommended to
   use Full Intra Request (FIR) feedback messages [RFC5104] with Haptics.
-->

The RTP payload header follows the RTP header. {{figure-payloadheader}} describes the RTP payload header for Haptic.

~~~~~~~~~~ aasvg
+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|D| UT  |   L   |
+-+-----+-------+
~~~~~~~~~~
{: #figure-payloadheader title="RTP Payload Header for Haptic."} Haptic"}

D (Dependency, 1 bit): this
: This field is used to indicate indicates whether the MIHS unit included in the RTP payload is, when is dependent (when its value is one, dependent or, when one) or independent (when its value is zero, independent. zero).

UT (Unit Type, 3 bits): this
: This field indicates the type of the MIHS unit included in the RTP payload. UT field values are listed in {{figure-transmission-type}}.

L (MIHS Layer, 4 bits): this
: This field is an integer value which that indicates the priority order of the MIHS unit included in the RTP payload, as determined by the haptic sender (e.g., by the haptic codec), based on application-specific needs. For example, the sender may use the MIHS layer to prioritize perceptions with the largest impact on the end-user experience. Zero corresponds to the highest priority. The semantic of individual MIHS layers are not specified and are left for the application to assign. In cases where the sender does not use the L field to indicate the priority order of the MIHS unit, the L value is '0'.

## Payload Structures

Three different types of RTP packet payload structures are specified. A single unit packet contains a single MIHS unit in the payload.  A fragmentation unit contains a subset of a MIHS unit. An aggregation packet contains multiple MIHS units in the payload. The unit type (UT) field of the RTP payload header, as shown in  {{figure-transmission-type}}, identifies both the payload structure and, in the case of a single-unit structure, also identifies the type of MIHS unit present in the payload.

~~~~~~~~~~ aasvg

| Unit Type | Payload Structure  | Packet Type Name
Type     Structure
-------------------------------------------------------          |
|:----------------------------------------------------------:|
| 0     |   N/A      | Unassigned                            |
| 1     |   Single   | Initialization MIHS Unit              |
| 2     |   Single   | Temporal MIHS Unit                    |
| 3     |   Single   | Spatial MIHS Unit                     |
| 4     |   Single   | Silent MIHS Unit                      |
| 5     |   Aggr     | Single-Time Aggregation Packet (STAP) |
| 6     |   Aggr     | Multi-Time Aggregation Packet (MTAP)  |
| 7     |   Frag     | Fragmentation Unit
~~~~~~~~~~                    |
{: #figure-transmission-type title="Payload structure type Structure Type for haptic"} Haptic"}

The payload structures are represented in {{figure-transmission-style}}.  The single unit payload structure is specified in {{single}}. The fragmented unit payload structure is specified in {{fragmented}}. The aggregation packet payload structure is specified in {{aggregated}}.  The padding in the figures of these section sections refers to the RTP padding defined in {{RFC3550}}.

~~~~~~~~~~ aasvg
                                            +-------------------+
                                            |     RTP Header    |
                                            +-------------------+
                                            | RTP Payload Header|
                      +-------------------+ |   (UT = Aggr)     |
                      |     RTP Header    | +-------------------+
+-------------------+ +-------------------+ |  MIHS unit Unit 1 Size |
|     RTP Header    | | RTP Payload Header| +-------------------+
+-------------------+ |   (UT = Frag)     | |    MIHS Unit 1    |
| RTP Payload Header| +-------------------+ +-------------------+
+-------------------+ |     FU Header     | |  MIHS unit Unit 2 Size |
|    RTP Payload    | +-------------------+ +-------------------+
| (Single MIHS unit)| |    RTP Payload    | |       ...         |
+-------------------+ +-------------------+ +-------------------+

(a) single unit      (b)fragmentation unit (c) aggregation packet

~~~~~~~~~~
{: #figure-transmission-style  title="RTP Transmission modes"} Modes"}

### Single Unit Payload Structure {#single}

In a single unit payload structure, as described in {{figure-transmission-single}}, the RTP packet contains the RTP header, followed by the payload header and one single MIHS unit. The payload header follows the structure described in {{payload-header}}. The  payload contains a MIHS unit as defined in {{ISO.IEC.23090-31}}.

~~~~~~~~~~ aasvg
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Header |                                               |
+---------------+                                               |
|                        MIHS Unit Data                         |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |...OPTIONAL RTP padding Padding        |
+-------------------------------+-------------------------------+
~~~~~~~~~~
{: #figure-transmission-single  title="Single Unit Payload Structure"}

### Fragmented Unit Payload Structure {#fragmented}

In a fragmented unit payload structure, as described in {{figure-fragment-structure}}, the RTP packet contains the RTP header, followed by the payload header, a Fragmented Unit (FU) header, and a MIHS unit fragment. The payload header follows the structure described in {{payload-header}}. The value of the UT field of the payload header is 7. The FU header follows the structure described in {{figure-fragment-header}}. In the case of fragmentation, all RTP payload header fields MUST remain unchanged across all fragments.

~~~~~~~~~~ aasvg
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Header | FU Header     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                     MIHS Unit Fragment                        |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |...OPTIONAL RTP Padding        |
+-------------------------------+-------------------------------+
~~~~~~~~~~
{: #figure-fragment-structure title="Fragmentation Unit Payload Structure"}

FU headers are used to enable fragmenting a single MIHS unit into multiple RTP packets. Fragments of the same MIHS unit MUST be sent in consecutive order with ascending RTP sequence numbers (with no other RTP packets within the same RTP stream being sent between the first and last fragment). FUs MUST NOT be nested, i.e., an FU MUST NOT contain a subset of another FU.

{{figure-fragment-header}} describes a an FU header, including the following fields:

~~~~~~~~~~ aasvg
+---+---+---+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+---+---+---+---+---+---+---+
|FUS|FUE|   RSV     |     UT    |
+---+---+-----------+-----------+
~~~~~~~~~~
{: #figure-fragment-header title="Fragmentation unit header"} Unit Header"}

FUS (Fragmented Unit Start, 1 bit): this
: This field MUST be set to 1 for the first fragment, fragment and 0 for the other fragments.

FUE (Fragmented Unit End, 1 bit): this
: This field MUST be set to 1 for the last fragment, fragment and 0 for the other fragments.

The combination FUS=1 and FUE=1 MUST NOT occur; such packets are invalid.

RSV (Reserved, 3 bits): these
: These bits MUST be set to 0 by the sender and ignored by the receiver.

UT (Unit Type, 3 bits): this
: This field indicates the type of the MIHS unit this fragment belongs to, using values defined in {{figure-transmission-type}}.

The use of MIHS unit fragmentation in RTP means that a media receiver can receive some fragments, but not other fragments. The missing fragments will typically not be retransmitted by RTP. This results in partially received MIHS units, which can be either dropped or used by the decoding application, based on implementation. In cases where consecutive fragments with FUE and FUS are lost, the receiver may in some cases be able to detect that surrounding fragments belong to a different partially received MIHS unit (e.g., if the UT field holds a different value).

### Aggregation Packet Payload Structure {#aggregated}

In an aggregation packet, as described in {{figure-aggre-structure}}, the RTP packet contains an RTP header, followed by a payload header, and, for and (for each aggregated MIHS Unit, unit) a MIHS unit size followed by the MIHS unit. The payload header follows the structure described in {{payload-header}}.

~~~~~~~~~~ aasvg
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          RTP Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        RTP Payload Header     |       MIHS Unit 1 Size        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           MIHS Unit 1                         |
    |                                                               |
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        MIHS Unit 2 Size     |                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
    |                           MIHS Unit 2                         |
    |                                                               |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |...OPTIONAL RTP padding Padding        |
    +-------------------------------+-------------------------------+
~~~~~~~~~~
{: #figure-aggre-structure title="Single-Time Aggregation Packet"}

{{figure-aggre-structure}} shows a Single-Time Aggregation Packet (STAP), which can be used to transmit multiple MIHS units that correspond to the same timestamp. For example, if two frequencies are used for the same content, they can be transmitted at once in a STAP. Multiple spatial units can also be sent together in a STAP, since this type of haptics data is time independent. The MIHS unit length field (16 bits) holds the length of the MIHS unit following it, in bytes. The value of the UT field of the payload header is 5.

<!--[rfced] FYI: In Figure 9, we moved the bit ruler over one space
to the right to get the correct alignment (this is consistent with
the other figures that contain bit rulers). Please let us know of
any objections.
-->

~~~~~~~~~~ aasvg
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          RTP Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        RTP Payload Header     |       MIHS Unit 1 Size        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           TS Offset           |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    |                           MIHS Unit 1                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MIHS Unit 2 Size        |            TS Offset          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   TS offset Offset   |                                               |
    |-+-+-+-+-+-+-+-+                                               |
    |                          MIHS Unit 2                          |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |...OPTIONAL RTP padding Padding        |
    +-------------------------------+-------------------------------+
~~~~~~~~~~
{: #figure-aggremtap-structure title="Multiple-time aggregation packet"} title="Multiple-Time Aggregation Packet"}

{{figure-aggremtap-structure}} shows a multi-time aggregation packet. Multi-Time Aggregation Packet (MTAP). It is used to transmit multiple MIHS units with different timestamps, in one RTP packet. Multi-time aggregation can help reduce the number of packets, packets in environments where some delay is acceptable. The value of the UT field of the Payload Header payload header is 6. The MIHS unit length field (16 bits) holds the length of the MIHS unit following it, in bytes. The timestamp offset field (TS offset, 16 bits) is present in the MTAP case, case and MUST be set to the value of (time of the MIHS unit - RTP timestamp of the packet).  The timestamp offset of the earliest aggregation unit MUST always be zero. Therefore, the RTP timestamp of the MTAP is identical to the earliest MIHS unit time.

## MIHS Units Transmission and Reception Considerations {#mihs-trans}

The following considerations apply for the streaming of MIHS units over RTP: RTP.

The MIHS format enables variable duration units and uses initialization MIHS units to declare the duration of subsequent non-zero duration MIHS units, as well as the maximum variation of this duration. A sender SHOULD set constant or low-variability (e.g., lower than the playout buffer) durations in initialization MIHS units, for RTP streaming. This enables the receiver to determine early (e.g., using a timer) when a unit has been lost and to make the decoder more robust to RTP packet loss. If a sender sends MIHS units with high duration variations, the receiver MAY need to wait for a long period of time (e.g., the upper bound of the duration variation), variation) to determine if a MIHS unit was lost in transmission. Whether this behavior is acceptable or not is application dependent, and the application can configure the encoder to generate MIHS unit of lengths with the appropriate variation.

The MIHS format uses silent MIHS units to signal haptic silence. A sender MAY decide not to send silent units, to save network resources. Since, from a receiver standpoint, a missed MIHS unit may originate from a not-sent silent unit, unit or a lost packet, a sender MAY send one, or a few, MIHS silent units at the beginning of a haptic silence. If a media receiver receives a MIHS silent unit, the receiver SHOULD assume that silence is intended until the reception of a non-silent MIHS unit. This can reduce the number of false detections of lost RTP packets by the decoder.

In some multimedia conference scenarios using an RTP video mixer (e.g., when adding or selecting a new source), it is recommended to use Full Intra Request (FIR) feedback messages {{RFC5104}} with Haptics {{RFC5104}}. Haptics. The purpose of the FIR message is to cause an encoder to send a decoder refresh point at the earliest opportunity. In the context of haptics, an appropriate decoder refresh point is an initialization MIHS unit. The initialization MIHS unit point enables a decoder to be reset to a known state and be able to decode all MIHS units following it.

# Payload Format Parameters

This section describes payload format parameters. {{optional-param}} specifies new optional parameters parameters, and {{sdp-registration}} further registers a new token in the media sub-registry subregistry of the Session "Session Description Protocols Protocol (SDP) Parameters registry. Parameters" registry group.

## Optional Parameters Definition  {#optional-param}

It is optional to include the SDP parameters in this section. Some parameters have a default value which that MUST be inferred if the parameter is not present in the SDP, unless an out-of-band agreement indicates a different value, as described in {{sdp-cons}}. The values of the SDP parameters indicated in this section are based on the current version of the MPEG Haptics Coding standard (ISO/IEC 23090-31:2025) and may be different in future versions of {{ISO.IEC.23090-31}}.

<!--[rfced] In the list in section 6.1, please clarify "may hold values among" (3 instances). Does this
mean "may contain the values"? Also, is "or" (before "Custom")
correct, or should it be "and/or"?

One example

Original:
   The avatar type is defined in [ISO.IEC.23090-31]:
   MPEG_haptics.avatar object.type is a string which may hold values
   among "Vibration", "Pressure", "Temperature", "Custom".

Perhaps:
   The avatar type is defined in [ISO.IEC.23090-31]:
   MPEG_haptics.avatar object.type is a string that may contain the
   values "Vibration", "Pressure", "Temperature", or "Custom".
-->

ver:

This parameter provides the year of the edition and amendment of ISO/IEC 23090-31 that this file conforms to, as defined in {{ISO.IEC.23090-31}}: MPEG_haptics object.version is a string which that may hold values such as XXXX or XXXX-Y where XXXX is the year of publication and Y is the amendment number, if any. For the initial (and current) version of the MPEG Haptics Coding standard (ISO/IEC 23090-31:2025) , 23090-31:2025), the value is "2025". When ver is not present, a default value of "2025" SHOULD be inferred.

profile:
: This parameter indicates the profile used to generate the encoded stream stream, as defined in {{ISO.IEC.23090-31}}: MPEG_haptics object.profile is a string which that may hold the values "simple-parametric" or "main". When profile is not present, the default value "main" SHOULD be inferred.

lvl:
: This parameter indicates the level used to generate the encoded stream stream, as defined in {{ISO.IEC.23090-31}}: MPEG_haptics object.level is an integer which that may hold the values 1 or 2. When lvl is not present, the default value 2 SHOULD be inferred.

maxlod:
: This parameter indicates the maximum level of details (LODs) to use for the avatar(s). The avatar level of detail (LOD) LOD is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.avatar object.lod is an integer which that may hold the value 0 or a positive integer.

avtypes:
: This parameter indicates, using a comma-separated list, the types of haptic perception represented by the avatar(s). The avatar type is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.avatar object.type is a string which that may hold values among "Vibration", "Pressure", "Temperature", or "Custom".

modalities:
: This parameter indicates, using a comma-separated list, haptic perception modalities (e.g., pressure, acceleration, velocity, position, temperature, etc.). The perception modality is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.perception object.perception_modality is a string which that may hold values among "Pressure", "Acceleration", "Velocity", "Position", "Temperature", "Vibrotactile", "Water", "Wind", "Force", "Electrotactile", "Vibrotactile Texture", "Stiffness", "Friction", "Humidity", "User-defined Temporal", "User-defined Spatial", or "Other".

bodypartmask:
: This parameter is an integer which that indicates, using a bitmask, the location of the devices or actuators on the body. The body part mask is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.body_part_mask is a 32-bit integer which that may hold a bit mask using bit positions defined in table Table 7 of {{ISO.IEC.23090-31}}.

maxfreq:
: This parameter is an integer which that indicates the maximum frequency of haptic data for vibrotactile perceptions (Hz). Maximum frequency is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.maximum_frequency.

minfreq:
: This parameter is an integer which that indicates the minimum frequency of haptic data for vibrotactile perceptions (Hz). Minimum frequency is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.minimum_frequency.

dvctypes:
: This parameter is an integer that indicates, using a comma-separated list, the types of actuators. The device type is defined in {{ISO.IEC.23090-31}}: MPEG_haptics.reference_device object.type is a string which that may hold values among "LRA", "VCA", "ERM", "Piezo" "Piezo", or "Unknown".

silencesupp:
: This parameter is an integer which that indicates whether silence suppression should be used (1) (value 1) or not (0). (value 0). When silencesupp is not present, the default value 0 SHOULD be inferred.

## SDP Parameter Registration {#sdp-registration}

This memo registers a 'haptics' token in the media sub-registry subregistry of the Session "Session Description Protocols Protocol (SDP) Parameters registry. Parameters" registry group. This registration contains the required information elements outlined in the SDP registration procedure defined in section {{Section 8.2 of {{RFC8866}}. RFC8866}}.

<!--[rfced] Please note that we updated the registration
template in Section 6.2 as follows. Please let us know of any objections.

Original:
  (1) Contact Information:

       Name: Hyunsik Yang
       Email: hyunsik.yang@interdigital.com

  (2) Name being registered (as it will appear in SDP): haptics

  (3) Long-form name in English: haptics

  (4) Type of name ('media', 'proto', 'fmt', 'bwtype', 'nettype',
           or 'addrtype'): media

  (5) Purpose of the registered name:

       The 'haptics' media type for the Session Description Protocol
       is used to describe a media stream whose content can be
       rendered as touch-related sensations.
       The media subtype further describes the specific
       format of the haptics stream.  The 'haptics' media type for
       SDP is used to establish haptics media streams.

  (6) Specification for the registered name: RFC XXXX

Current:
   Contact name:  Hyunsik Yang

   Contact email address:  hyunsik.yang@interdigital.com

   Name being defined (as it will appear in SDP):  haptics

   Type of name:  media

   Description:  The 'haptics' media type for the Session Description
      Protocol is used to describe a media stream whose content can be
      rendered as touch-related sensations.  The media subtype further
      describes the specific format of the haptics stream.  The
      'haptics' media type for SDP is used to establish haptics media
      streams.

   Reference:  RFC Editor Note: Replace RFC XXXX with 9993
-->

   Contact name:
   : Hyunsik Yang

   Contact email address:
   : hyunsik.yang@interdigital.com

   Name being defined (as it will appear in SDP):
   : haptics

   Type of name:
   : media

   Description:
   : The 'haptics' media type for the Session Description Protocol
   is used to describe a media stream whose content can be rendered
   as touch-related sensations.  The media subtype further describes
   the published specific format of the haptics stream.  The 'haptics' media
   type for SDP is used to establish haptics media streams.

   Reference:
   : RFC number. 9993

# SDP Considerations

The mapping of above defined the above-defined payload format media type to the corresponding fields in the Session Description Protocol (SDP) SDP is done according to {{RFC8866}}.

The media name in the "m=" line of SDP MUST be haptics.

The encoding name in the "a=rtpmap" line of SDP MUST be hmpg hmpg.

The clock rate in the "a=rtpmap" line may be any sampling rate, typically 8000.

The optional parameters (defined in {{optional-param}}), when present, MUST be included in the "a=fmtp" line of SDP. This is expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. Parameter values, including string values, MUST be written without quotation marks ("") in SDP. Parameter values which that are strings are not case sensitive and SHOULD be written in lowercase.

An example of media representation corresponding to the hmpg RTP payload in SDP is as follows:

<!--[rfced] The figure in Section 7 is marked as artwork. Please
confirm if this is correct or if it should be marked as sourcecode
instead.

If it is marked as sourcecode, please consider whether the "type"
attribute should be set.

The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->

~~~
    m=haptics 43291 UDP/TLS/RTP/SAVPF 115
    a=rtpmap:115 hmpg/8000
    a=fmtp:115 profile=main;lvl=1;ver=2025
~~~

## SDP Offer/Answer Considerations {#sdp-cons}

When using the offer/answer procedure described in {{RFC3264}} to negotiate the use of haptic, the following considerations apply:

When used for a unidirectional stream, the SDP parameters represent the properties of the sender (on the sending side) and of the receiver (on the receiving side). When used for a sendrecv stream, the SDP parameters represent the properties of the receiver.

The receiver properties expressed using the SDP parameters 'ver', 'profile' 'profile', and 'lvl' correspond to implementation capabilities. The ver, profile, and lvl parameters MUST be used symmetrically in SDP offer and answer. That is, their values in the answer MUST match those in the offer, either explicitly signaled or implicitly inferred. In the same session, ver, profile, and lvl MUST NOT be changed in subsequent offers or answers.

The properties expressed using SDP parameters other than 'ver', 'profile' 'profile', and 'lvl' are provided as recommendations for efficient data transmission and are not binding, meaning that a sender is encouraged but not required to conform to the parameters specified by the receiver. These properties MAY be set to different values in offers and answers. These properties MAY be updated in subsequent offers or answers.

Any receiver compliant with {{ISO.IEC.23090-31}} MUST be capable of decoding any stream with a compatible version, profile, and level. A receiver supporting a more general profile will accept a stream corresponding to a the same or a less general profile (e.g., "main" is more general than "simple-parametric"). A receiver supporting a given level will accept a stream corresponding to a the same or a lower level. A receiver supporting a given version will accept a stream corresponding to the same version and MAY accept other versions. A receiver MAY ignore any part of a received stream, e.g., that it does not have support for rendering.

The haptic signal can be sampled at different rates. The MPEG Haptics Coding standard does not mandate a specific frequency. A typical sample rate is 8000Hz.

<!--[rfced] May we remove the second sentence below? It appears to be
duplicate information from the first sentence.

Original:
   The parameter 'ver' indicates the version of the haptic standard
   specification. If it is not specified, the The parameter 'ver'
   indicates the version of the haptic standard specification. If it is
   not specified, the value "2025" indicating the MPEG Haptics Coding
   standard ISO/IEC 23090-31:2025 {{ ISO.IEC.23090-31}} [ISO.IEC.23090-31] SHOULD be inferred,
   although the sender and receiver MAY use a specific value based on an
   out-of-band agreement.

Perhaps:
   The parameter 'ver' indicates the version of the haptic standard
   specification. If it is not specified, the value "2025" indicating
   the MPEG Haptics Coding standard ISO/IEC 23090-31:2025
   [ISO.IEC.23090-31] SHOULD be inferred, although the sender and
   receiver MAY use a specific value based on an out-of-band
   agreement.
-->

The parameter 'ver' indicates the version of the haptic standard specification. If it is not specified, the parameter 'ver' indicates the version of the haptic standard specification. If it is not specified, the value "2025" indicating the MPEG Haptics Coding standard ISO/IEC 23090-31:2025 {{ISO.IEC.23090-31}}  SHOULD be inferred, although the sender and receiver MAY use a specific value based on an out-of-band agreement. The parameter 'profile' is used to restrict the number of tools used (e.g., the simple-parametric profile fits enable enables simpler implementations than the main profile). If it is not specified, the most general profile "main" SHOULD be inferred, although the sender and receiver MAY use a specific value based on an out-of-band agreement. The parameter 'lvl' is used to further characterize implementations within a given profile, e.g., according to the maximum supported number of channels, bands, and perceptions. If it is not specified, the most general level "2" SHOULD be inferred, although the sender and receiver MAY use a specific version based on an out-of-band agreement.

<!--[rfced] We note "body-part-mask" as well as "body part mask"
(as defined in [ISO.IEC.23090-31]). Should the hyphenated form be
updated as shown below for consistency?

Original:
   In some other cases, some receivers MAY indicate a preference for a
   set of bitstream properties such as perceptions, min/max frequency,
   or body-part-mask, which contribute ...

Perhaps:
   In some other cases, some receivers MAY indicate a preference for a
   set of bitstream properties such as perceptions, min/max frequency,
   or body part mask, which contribute ...
-->

Other parameters can be used to indicate bitstream properties as well as receiver capabilities. The parameters 'maxlod', 'avtypes', 'bodypartmask', 'maxfreq', 'minfreq', 'dvctypes', and 'modalities' can be sent by a sender to reflect the characteristics of bitstreams and can be set by a receiver to reflect the nature and capabilities of local actuator devices, devices or a preferred set of bitstream properties. For example, different receivers MAY have different sets of local actuators, in which case these parameters can be used to select a stream adapted to the receiver. In some other cases, some receivers MAY indicate a preference for a set of bitstream properties such as perceptions, min/max frequency, or body-part-mask, which contribute the most to the user experience for a given application, in which case these parameters can be used to select a stream which include that includes and possibly prioritizes those properties. For example, if the haptic stream server provides more information than the body mask specified by the receiver, the additional information can be either integrated into a single effect or ignored by the receiver.

The parameter 'silencesupp' can be used to indicate sender and receiver capabilities or preferences. This parameter indicates whether silence suppression should be used, as described in {{mihs-trans}}. If it is not specified, the value "0", indicating no silence suppression, SHOULD be inferred, although the sender and receiver MAY use silence suppression based on an out-of-band agreement.

## Declarative SDP Considerations

When haptic content over RTP is offered with SDP in a declarative style, the parameters capable of indicating both bitstream properties as well as receiver capabilities are used to indicate only bitstream properties.  For example, in this case, the parameters maxlod, bodypartmask, maxfreq, minfreq, dvctypes, 'maxlod', 'bodypartmask', 'maxfreq', 'minfreq', 'dvctypes', and modalities 'modalities' declare the values used by the bitstream, not the capabilities for receiving bitstreams. A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver MUST reject or not participate in the session.  It falls on the creator of the session to use values that are expected to be supported by the receiving application.

# Congestion Control Considerations

<!--[rfced] We note only one instance of "HMPG" - is this correct, or
should it be lowercase? If it should remain as uppercase, how may we
expand it?

Original:
   The general congestion control considerations for transporting RTP
   data apply to HMPG haptics over RTP as well [RFC3550]
-->

The general congestion control considerations for transporting RTP data apply to HMPG haptics over RTP as well {{RFC3550}}.

It is possible to adapt network bandwidth usage by adjusting either the encoder bit rate or by adjusting the stream content (e.g., level of detail, the LOD, body parts, actuator frequency range, target device types, and modalities). The considerations in this section are applicable to best-effort networks and controlled environments.

<!--[rfced] May we revise this text to be two sentences to improve
readability?

Original:
   In case of congestion, a receiver or intermediate node MAY prioritize
   initialization MIHS units over other units, since initialization MIHS
   units contain metadata used to re-initialize the decoder, and MAY drop
   silent MIHS units before other types of MIHS units, since a receiver
   MAY interpret a missing MIHS unit as a silence.

Perhaps:
   In case of congestion, a receiver or intermediate node MAY prioritize
   initialization MIHS units over other units, as these contain metadata
   that is used to reinitialize the decoder. Additionally, a receiver or
   intermediate node MAY drop silent units before other types, as a
   receiver MAY interpret a missing unit as silence.
-->

In case of congestion, a receiver or intermediate node MAY prioritize independent packets over dependent ones, since the non-reception of an independent MIHS unit can prevent the decoding of multiple subsequent dependent MIHS units. In case of congestion, a receiver or intermediate node MAY prioritize initialization MIHS units over other units, since initialization MIHS units contain metadata used to re-initialize reinitialize the decoder, and MAY drop silent MIHS units before other types of MIHS units, since a receiver MAY interpret a missing MIHS unit as a silence. It is also possible, using the layer field of the RTP payload header, to allocate MIHS units to different layers based on their content, content to prioritize haptic data contributing that contributes the most to the user experience. In case of congestion, intermediate nodes and receivers SHOULD use the MIHS layer value to determine the relative importance of haptic RTP packets.

Receivers should monitor timestamps and treat gaps as loss of the corresponding MIHS units. MIHS units, as defined in {{ISO.IEC.23090-31}}, should be checked for structural integrity according to their type. When CRC16 or CRC32 information is present in MIHS units, receivers must validate data integrity, and units failing CRC checks Cyclic Redundancy Checks (CRCs) should be treated as lost. Receivers should further monitor indicators of service degradation such as unexpected silent gaps, repeated decoder reinitializations, or decoding failures. Receivers should report packet loss to the sender using RTCP Receiver Reports {{RFC3550}} and, when available, may report detailed loss and jitter metrics using mechanisms described in {{RFC4585}}.

# Security Considerations

This

The RTP payload format is subject to security threats commonly associated with RTP payload formats, as well as threats specific to the interaction of haptic devices with the physical world, world and threats associated with the use of compression by the codec.
Security consideration considerations for threats commonly associated with RTP payload formats are outlined in {{RFC3550}}, as well as in RTP profiles such as RTP/AVP {{RFC3551}}), {{RFC3551}}, RTP/AVPF {{RFC4585}}, RTP/SAVP {{RFC3711}}, or and RTP/SAVPF {{RFC5124}}.

Haptic sensors and actuators operate within the physical environment. This introduces the potential for information leakage through sensors, sensors or damage to actuators due to data tampering. Additionally, misusing the functionalities of actuators (such as force, position, temperature, vibration, electro-tactile, electrotactile, etc.) may pose a risk of harm to the user, for example example, by setting keyframe parameters (e.g., amplitude, position, and frequency) or channel gain to a value that surpasses a permissible range. While individual devices can implement security measures to reduce or eliminate those risks on a per-device basis, in some cases cases, harm can be inflicted by setting values which that are permissible for the individual device. For example, causing contact with the physical environment or triggering unexpected force feedback can potentially harm the user. Each haptic system should therefore implement system-dependent security measures, which are more error prone. To limit the risk that attackers exploit weaknesses in haptic systems, it is important that haptic transmission should be protected against malicious traffic injection or tampering.

However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" {{RFC7202}} discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. The responsibility for implementing security mechanisms lies with the application developer. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" {{RFC7201}}, although {{RFC7201}} is now considered dated and several mechanisms described therein have since evolved.

Applications SHOULD use appropriate and current strong security mechanisms. For modern best practices, applications can consider the following options:

<!--[rfced] BCP 195 contains RFCs 8996 and 9325. Should there be a
reference to BCP 195 in this sentence (with a corresponding entry under
the Informative References section), or is the reference to [RFC9325]
sufficient?

Current:
   (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS,
   applications should refer to BCP 195, including [RFC9325], which
   provides up-to-date recommendations.
-->

- (D)TLS-based protection:
  For guidance on using TLS 1.3 and DTLS, applications should refer to BCP 195,
  including {{RFC9325}}, which provides up-to-date recommendations.

- IPsec-based protection:
Relevant and current protocol specifications include {{RFC4303}} (ESP) ("IP Encapsulating Security Payload (ESP)") and {{RFC7296}} (IKEv2). ("Internet Key Exchange Protocol Version 2 (IKEv2)").

This document does not mandate a specific security mechanism. Instead, applications are responsible for selecting mechanisms that follow current best practices for confidentiality, integrity, and source authentication, authentication and that reflect the evolving security landscape beyond what is covered in {{RFC7201}}.

The haptic codec used with this payload format uses a compression algorithm (see sections Sections 8.2.8.5 and 8.3.3.2 in {{ISO.IEC.23090-31}}). An attacker may inject pathological datagrams into the stream which that are complex to decode and cause the receiver to be overloaded, similarly to {{RFC3551}}.

End-to-end security with authentication, integrity, or confidentiality protection will prevent a Media-Aware Network Element (MANE) from performing media-aware operations other than discarding complete packets. In the case of confidentiality protection, it will even be prevented from discarding packets in a media-aware way. To be allowed to perform such operations, a MANE is required to be a trusted entity that is included in the security context establishment.

# IANA Considerations

## Media Type Registration Update

This memo updates the 'hmpg' haptic subtype defined in {{RFC9695}} for use with the MPEG-I haptics streamable binary coding format described in ISO/IEC 23090-31: Haptics coding {{ISO.IEC.23090-31}}. This memo especially defines optional parameters for this type in {{optional-param}}. The original subtype registration for haptics/hmpg, 'haptics/hmpg', registered with IANA in {{RFC9695}}, did not include any required or optional parameters. This document introduces optional parameters to enable extended functionality while maintaining backward compatibility.

A mapping of the parameters into the Session Description Protocol (SDP) SDP {{RFC8866}} is also provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP. The receiver MUST ignore any parameter unspecified in this memo.

This document requests an SDP parameters

IANA has updated the registration for the haptic media type, as 'haptics', described in {{sdp-registration}}. {{sdp-registration}}, in the "haptics" registry within the "Media Types" registry group and listed document as an additional reference.

The following entries identify the media type being updated: updates to the 'media/haptics' registration:

Type name:
: haptics

Subtype name:
: hmpg

The following entries are replaced by this memo:

Optional parameters: see section 6.2
: See {{sdp-registration}} of RFC XXX (note to RFC editor: replace with this RFC's number). 9993

Person & email address to contact for further information: Yeshwant Muthusamy
: {{{Yeshwant Muthusamy}}} (yeshwant@yeshvik.com) and Hyunsik Yang {{{Hyunsik Yang}}} (hyunsik.yang@interdigital.com)

<!-- [rfced] We had trouble matching up the text in the IANA Considerations with the IANA registrations.  We have attempted to make the text more clear.  This includes adding a section 10.2 to specify the new SDP parameters media registration.

Please review carefully and let us know if any updates are needed.
-->

## New SDP Parameters Media Registration

IANA has registered the following in the "media" registry within the "Session Description Protocol (SDP) Parameters" registration group.

| Type | SDP Name | Reference |
|:---------------------------:|
|media | haptics  | RFC 9993  |

--- back

# Acknowledgments
{:numbered="false"}

Thanks to Philippe Guillotel, Quentin Galvane, Jonathan Lennox, Marius Kleidl {{{Philippe Guillotel}}}, {{{Quentin Galvane}}}, {{{Jonathan Lennox}}}, {{{Marius Kleidl}}}, and Stephan Wenger {{{Stephan Wenger}}} for the comments and discussions about this draft. document.

<!--[rfced] FYI: We have added an expansion for the following
abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide").
Please review this as well as each expansion in the document
carefully to ensure correctness.

 Cyclic Redundancy Checks (CRCs)
-->

<!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->