RTP Payload for Haptics
draft-hsyang-avtcore-rtp-haptics-00

avtcore                                                          HS Yang
Internet-Draft                                                 X. de Foy
Intended status: Standards Track                            InterDigital
Expires: 18 April 2024                                   16 October 2023

                        RTP Payload for Haptics
                  draft-hsyang-avtcore-rtp-haptics-00

Abstract

   This memo describes an RTP payload format for the MPEG-I haptic data.
   A haptic media stream is composed of MIHS units including a MIHS 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 April 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

HS Yang & de Foy          Expires 18 April 2024                 [Page 1]
Internet-Draft             RTP-Payload-Haptic               October 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Haptic Format Description . . . . . . . . . . . . . . . . . .   4
     4.1.  Overview of Haptic Coding . . . . . . . . . . . . . . . .   4
     4.2.  MPEG-I Haptic Stream (MIHS) format  . . . . . . . . . . .   4
     4.3.  MIHS transmission Considerations  . . . . . . . . . . . .   5
   5.  Payload format for haptics  . . . . . . . . . . . . . . . . .   5
     5.1.  RTP header Usage  . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Payload Header  . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Payload Structures  . . . . . . . . . . . . . . . . . . .   7
       5.3.1.  Single Unit Payload Structure . . . . . . . . . . . .   8
       5.3.2.  Fragmented Unit Payload Structure . . . . . . . . . .   9
   6.  Payload format parameters . . . . . . . . . . . . . . . . . .  10
     6.1.  Media type registration . . . . . . . . . . . . . . . . .  10
     6.2.  Optional parameters definition  . . . . . . . . . . . . .  10
   7.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  SDP Offer/Answer Considerations . . . . . . . . . . . . .  12
     7.2.  Declarative SDP considerations  . . . . . . . . . . . . .  13
   8.  Congestion control consideration  . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  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 them
   with information to operate according to the values defined in haptic
   effects.  The IETF is registering haptics as a primary media type
   akin to audio and video [I-D.ietf-mediaman-haptics].

   The MPEG Haptics Coding standard [ISO.IEC.23090-31] defines the data
   formats, metadata, and codec architecture to encode, decode,
   synthesize and transmit haptic signals.  It defines the "MIHS unit"
   as a unit of packetization suitable for streaming, and similar in
   essence to the NAL unit defined in some video specifications.  This
   document describes how haptic data (MIHS units) can be transmitted
   using the RTP protocol.  This document followed recommendations in
   [RFC8088] and [RFC2736] for RTP payload format writers.

HS Yang & de Foy          Expires 18 April 2024                 [Page 2]
Internet-Draft             RTP-Payload-Haptic               October 2023

2.  Conventions

   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 [RFC2119].

3.  Definition

   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 of a device for rendering haptic sensations.

   Avatar: body (or part of body) representation.

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

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

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

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

   Experience: top level haptic component containing perceptions and
   metadata.

   Haptics: tactile sensations.

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

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

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

   Perception: haptic perception containing channels of a specific
   modality.

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

HS Yang & de Foy          Expires 18 April 2024                 [Page 3]
Internet-Draft             RTP-Payload-Haptic               October 2023

4.  Haptic Format Description

4.1.  Overview of Haptic Coding

   The MPEG Haptics Coding standard specifies methods for efficient
   transmission and 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 kinaesthetic perceptions (tactile resistance), but
   also other, less common perceptions, including for example the sense
   of temperature or texture.  It also supports two approaches for
   encoding haptic signals: a "quantized" approach based on samples of
   measured 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 human-readable exchange format
   based on JSON (.hjif), or in a binary packetized format for
   distribution and streaming (.hmpg).  This last format is referred to
   as the MPEG-I Haptic Stream (MIHS) format and is a base for the RTP
   payload format described in this document.

4.2.  MPEG-I Haptic Stream (MIHS) format

   MIHS is a stream format used to transport haptic data.  Haptic data
   including haptic effects is packetized according to the MIHS format,
   and delivered to actuators, which operate according to the provided
   effects.  The MIHS format has two level 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 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
   and its duration is a positive number.

HS Yang & de Foy          Expires 18 April 2024                 [Page 4]
Internet-Draft             RTP-Payload-Haptic               October 2023

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

   Figure 1 illustrates a succession of MIHS units in a MIHS stream.

   +--------------+ +-------+ +----------+ +-------------+ +-----------+
   |Initialization| |Spatial| | Temporal | |Temporal Unit| |Silent Unit|
   |    Unit      |-| Unit  |-|Unit(sync)|-| (non-sync)  |-|  (sync)   |
   +--------------+ +-------+ +----------+ +-------------+ +-----------+

                      Figure 1: Example of MIHS stream

4.3.  MIHS transmission Considerations

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

   *  A media sender SHOULD set durations with the same value for all
      non-zero duration MIHS units between initialization MIHS units, to
      make the decoder more robust to RTP packet loss.

   *  A haptic silence suppression mechanism SHOULD be used.  A sender
      MAY send the first (or first few) MIHS silent units at the
      beginning of a haptic silence.  A sender SHOULD NOT send
      subsequent consecutive silent units, to save network resources.
      Following the reception of a MIHS silent unit, a receiver SHOULD
      interpret subsequent lost MIHS units as silent MIHS units, until
      the reception of a non-silent MIHS unit.

   TBD: these considerations may need to be re-evaluated depending on
   the finalization of the haptics coding specifications in MPEG.

5.  Payload format for haptics

5.1.  RTP header Usage

   The RTP header is defined in [RFC3550] and represented in Figure 2.
   Some of the header field values are interpreted as follows.

HS Yang & de Foy          Expires 18 April 2024                 [Page 5]
Internet-Draft             RTP-Payload-Haptic               October 2023

    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 2: RTP header for Haptic.

   Payload type (PT): 7 bits.  The assignment of a payload type MUST be
   performed either through the profile used or in a dynamic way.

   Time Stamp (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 (e.g., as an SDP parameter).

   Marker bit (M): 1 bit.  The marker bit SHOULD be set to one in the
   first non-silent RTP packet after 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.

5.2.  Payload Header

   The RTP Payload Header follows the RTP header.  Figure 3 describes
   RTP Payload Header.

   +---------------+
   |0|1|2|3|4|5|6|7|
   +-+-+-+-+-+-+-+-+
   |D| UT  |   L   |
   +-+-----+-------+

                  Figure 3: RTP payload header for Haptic.

HS Yang & de Foy          Expires 18 April 2024                 [Page 6]
Internet-Draft             RTP-Payload-Haptic               October 2023

   D (Dependency, 1 bit): this field is used to indicate whether the
   MIHS unit included in the RTP payload is, when its value is one,
   dependent (i.e., "non-sync") or, when its value is zero, independent
   (i.e., "sync").  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.

   UT (Unit Type, 3 bits): this field indicates the type of the MIHS
   unit included in the RTP payload.  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.  UT field values are listed in Figure 4.

   L (MIHS Layer, 4 bits): this field is an integer value which
   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.  In case of congestion, intermediate nodes and receivers
   SHOULD use the MIHS layer value to determine the relative importance
   of haptic RTP packets.

5.3.  Payload Structures

   Two different types of RTP packet payload structures are specified.
   The single unit payload structure contains a single MIHS unit.  The
   fragmented unit payload structure contains a subset of a MIHS unit.
   The unit type (UT) field of the RTP payload header Figure 4
   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.

   TBD: consider if it would be useful to add aggregation.

   Unit     Payload   Name
   Type     Structure
   ----------------------------------------
   0        N/A       Reserved
   1        Single    Initialization MIHS Unit
   2        Single    Temporal MIHS Unit
   3        Single    Spatial MIHS Unit
   4        Single    Silent MIHS Unit
   7        Frag      Fragmented Packet

HS Yang & de Foy          Expires 18 April 2024                 [Page 7]
Internet-Draft             RTP-Payload-Haptic               October 2023

                Figure 4: Payload structure type for haptic

   The payload structures are represented in Figure 4.  The single unit
   payload structure is specified in Section 5.3.1.  The fragmented unit
   payload structure is specified in Section 5.3.2.

                            +-------------------+
                            |     RTP Header    |
   +-------------------+    +-------------------+
   |     RTP Header    |    | RTP payload Header|
   +-------------------+    |   (UT = Frag)     |
   | RTP payload Header|    +-------------------+
   +-------------------+    |     FU Header     |
   |    RTP payload    |    +-------------------+
   | (Single MIHS unit)|    |    RTP Payload    |
   +-------------------+    +-------------------+
    (a) single unit RTP     (b) fragmented unit RTP

                      Figure 5: RTP Transmission mode

5.3.1.  Single Unit Payload Structure

   In a single unit payload structure, as described in Figure 5, 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 Section 5.2.  The payload contains a MIHS unit as
   defined in [ISO.IEC.23090-31].

    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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Single unit payload structure

HS Yang & de Foy          Expires 18 April 2024                 [Page 8]
Internet-Draft             RTP-Payload-Haptic               October 2023

5.3.2.  Fragmented Unit Payload Structure

   In a fragmented unit payload structure, as described in Figure 7, 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 Section 5.2.  The value of
   the UT field of the payload header is 7.  The FU header follows the
   structure described in Figure 8.

    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 7: Fragmentation unit header

   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 8 describes a FU header, including the following fields:

   +-------------------------------+
   |0  | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
   +---+---+---+---+---+---+---+---+
   |FUS|FUE|   RSV     |     UT    |
   +---+---+-----------+-----------+

                    Figure 8: Fragmentation unit header

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

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

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

HS Yang & de Foy          Expires 18 April 2024                 [Page 9]
Internet-Draft             RTP-Payload-Haptic               October 2023

   UT (Unit Type, 3 bits): this field indicates the type of the MIHS
   unit this fragment belongs to, using values defined in Figure 4.

6.  Payload format parameters

   This section specifies the optional parameters.  A mapping of the
   parameters into the Session Description Protocol (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.

6.1.  Media type registration

   The receiver MUST ignore any parameter unspecified in this memo.
   This memo defines the 'hmpg' haptic subtype for use with the MPEG-I
   haptics streamable binary coding format described in
   [ISO.IEC.23090-31].

   *  Type name: haptics

   *  Subtype name: hmpg

   *  Required parameters: N/A

   *  Optional parameters are defined in the following section.

6.2.  Optional parameters definition

   hmpg-ver 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].

   hmpg-profile indicates the profile used to generate the encoded
   stream as defined in [ISO.IEC.23090-31].  The current possible values
   are "simple-parametric" and "main".

   hmpg-lvl indicates the level used to generate the encoded stream as
   defined in [ISO.IEC.23090-31].

   hmpg-maxlod indicates the maximum level of details to use for the
   avatar(s).  The avatar level of detail (LOD) is defined in
   [ISO.IEC.23090-31].

   hmpg-avtypes indicates, using a coma-separated list, types of haptic
   perception represented by the avatar(s).  The avatar type is defined
   in [ISO.IEC.23090-31].

HS Yang & de Foy          Expires 18 April 2024                [Page 10]
Internet-Draft             RTP-Payload-Haptic               October 2023

   hmpg-modalities indicates, using a coma-separated list, haptic
   perception modalities (e.g., pressure, acceleration, velocity,
   position, temperature, etc.).  The perception modality is defined in
   [ISO.IEC.23090-31].

   hmpg-bodypartmask 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].

   hmpg-maxfreq indicates the maximum frequency of haptic data for
   vibrotactile perceptions (Hz).  Maximum frequency is defined in
   [ISO.IEC.23090-31].

   hmpg-minfreq indicates the minimum frequency of haptic data for
   vibrotactile perceptions (Hz).  Minimum frequency is defined in
   [ISO.IEC.23090-31].

   hmpg-dvctypes indicates, using a coma-separated list, the types of
   actuators.  The device type is defined in [ISO.IEC.23090-31].

   hmpg-silencesupp indicates whether silence suppression should be used
   (1) or not (0).  The default value shall be 1.

7.  SDP Considerations

   The mapping of above defined payload format media type to the
   corresponding fields in the Session Description Protocol (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

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

   The OPTIONAL parameters (defined in Section 6.2), 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.

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

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

HS Yang & de Foy          Expires 18 April 2024                [Page 11]
Internet-Draft             RTP-Payload-Haptic               October 2023

7.1.  SDP Offer/Answer Considerations

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

   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.

   The parameter 'hmpg-ver' indicates the version of the haptic standard
   specification.  If it is not specified, the initial version of the
   MPEG Haptic Coding specification SHOULD be assumed, although the
   sender and receiver MAY use a specific value based on an out-of-band
   agreement.  The parameter 'hmpg-profile' is used to restrict the
   number of tools used (e.g., the simple-parametric profile fits enable
   simpler implementations than the main profile).  If it is not
   specified, the most general profile "main" SHOULD be assumed,
   although the sender and receiver MAY use a specific value based on an
   out-of-band agreement.  The parameter 'hmpg-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 assumed,
   although the sender and receiver MAY use a specific version based on
   an out-of-band agreement.

   Other parameters can be used to indicate bitstream properties as well
   as receiver capabilities.  The parameters 'hmpg-maxlod', 'hmpg-
   avtypes', 'hmpg-bodypartmask', 'hmpg-maxfreq', 'hmpg-minfreq', 'hmpg-
   dvctypes', and 'hmpg-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, 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 and possibly
   prioritizes those properties.

   The parameter 'hmpg-silencesupp' can be used to indicate sender and
   receiver capabilities or preferences.  This parameter indicates
   whether silence suppression should be used, as described in
   Section 4.3.

HS Yang & de Foy          Expires 18 April 2024                [Page 12]
Internet-Draft             RTP-Payload-Haptic               October 2023

7.2.  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 hmpg-maxlod,
   hmpg-bodypartmask, hmpg-maxfreq, hmpg-minfreq, hmpg-dvctypes, and
   hmpg-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.

8.  Congestion control consideration

   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 by adjusting either the
   encoder bit rate or by adjusting the stream content (e.g., level of
   detail, body parts, actuator frequency range, target device types,
   modalities).  It is also possible, using the layer field of the RTP
   payload header, to allocate MIHS units to different layers based on
   their content, to prioritize haptic data contributing the most to the
   user experience.

9.  Security Considerations

   TBD

10.  IANA Considerations

   A new media type will be registered with IANA; see Section 6.

11.  References

11.1.  Normative References

   [ISO.IEC.23090-31]
              ISO/IEC, "ISO/IEC DIS 23090-31,Information technology -
              Coded representation of immersive media - Part 31: Haptics
              coding", ISO/IEC 23090-31, 2023,
              <https://www.iso.org/standard/86122.html>.

11.2.  Informative References

HS Yang & de Foy          Expires 18 April 2024                [Page 13]
Internet-Draft             RTP-Payload-Haptic               October 2023

   [I-D.ietf-mediaman-haptics]
              Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-level
              Media Type", Work in Progress, Internet-Draft, draft-ietf-
              mediaman-haptics-05, 27 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-
              mediaman-haptics-05>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
              Payload Format Specifications", BCP 36, RFC 2736,
              DOI 10.17487/RFC2736, December 1999,
              <https://www.rfc-editor.org/rfc/rfc2736>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/rfc/rfc3264>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.

   [RFC8088]  Westerlund, M., "How to Write an RTP Payload Format",
              RFC 8088, DOI 10.17487/RFC8088, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8088>.

   [RFC8866]  Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
              Session Description Protocol", RFC 8866,
              DOI 10.17487/RFC8866, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8866>.

Authors' Addresses

   Hyunsik Yang
   InterDigital
   United States of America
   Email: hyunsik.yang@interdigital.com

   Xavier de Foy
   InterDigital
   Canada
   Email: xavier.defoy@interdigital.com

HS Yang & de Foy          Expires 18 April 2024                [Page 14]