rfc9993v1.txt   rfc9993.txt 
skipping to change at line 262 skipping to change at line 262
The RTP header is defined in [RFC3550] and represented in Figure 2. The RTP header is defined in [RFC3550] and represented in Figure 2.
Unless contextualized below, the meaning of the fields depicted in Unless contextualized below, the meaning of the fields depicted in
Figure 2 is the same as in Section 5.1 of [RFC3550]. Figure 2 is the same as in Section 5.1 of [RFC3550].
0 1 2 3 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 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 | |V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp (TS) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Synchronization Source (SSRC) Identifier | | Synchronization Source (SSRC) Identifier |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Contributing Source (CSRC) Identifiers | | Contributing Source (CSRC) Identifiers |
| .... | | .... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: RTP Header for Haptic Figure 2: RTP Header for Haptics
Marker bit (M): 1 bit. The marker bit SHOULD be set to one in the 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. first non-silent RTP packet after a period of haptic silence.
This enables jitter buffer adaptation and haptics device washout This enables jitter buffer adaptation and haptics device washout
(i.e., reset to a neutral position) prior to the beginning of the (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 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. user. The marker bit in all other packets MUST be set to zero.
Timestamp (TS): 32 bits. A timestamp representing the sampling time Timestamp (TS): 32 bits. A timestamp representing the sampling time
of the first sample of the MIHS unit in the RTP payload. The 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 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 haptic data and is conveyed out of band (e.g., as an SDP
parameter). parameter).
5.2. Payload Header 5.2. Payload Header
The RTP payload header follows the RTP header. Figure 3 describes The RTP payload header follows the RTP header. Figure 3 describes
the RTP payload header for Haptic. the RTP payload header for haptics.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|D| UT | L | |D| UT | L |
+-+-----+-------+ +-+-----+-------+
Figure 3: RTP Payload Header for Haptic Figure 3: RTP Payload Header for Haptics
D (Dependency, 1 bit): This field indicates whether the MIHS unit D (Dependency): 1 bit. This field indicates whether the MIHS unit
included in the RTP payload is dependent (when its value is one) included in the RTP payload is dependent (when its value is one)
or independent (when its value is zero). or independent (when its value is zero).
UT (Unit Type, 3 bits): This field indicates the type of the MIHS UT (Unit Type): 3 bits. This field indicates the type of the MIHS
unit included in the RTP payload. UT field values are listed in unit included in the RTP payload. UT field values are listed in
Table 1. Table 1.
L (MIHS Layer, 4 bits): This field is an integer value that L (MIHS Layer): 4 bits. This field is an integer value that
indicates the priority order of the MIHS unit included in the RTP indicates the priority order of the MIHS unit included in the RTP
payload, as determined by the haptic sender (e.g., by the haptic payload, as determined by the haptic sender (e.g., by the haptic
codec), based on application-specific needs. For example, the codec), based on application-specific needs. For example, the
sender may use the MIHS layer to prioritize perceptions with the sender may use the MIHS layer to prioritize perceptions with the
largest impact on the end-user experience. Zero corresponds to largest impact on the end-user experience. Zero corresponds to
the highest priority. The semantic of individual MIHS layers are the highest priority. The semantic of individual MIHS layers are
not specified and are left for the application to assign. In not specified and are left for the application to assign. In
cases where the sender does not use the L field to indicate the cases where the sender does not use the L field to indicate the
priority order of the MIHS unit, the L value is '0'. priority order of the MIHS unit, the L value is '0'.
skipping to change at line 349 skipping to change at line 349
+-----------+-------------------+--------------------------+ +-----------+-------------------+--------------------------+
| 5 | Aggr | Single-Time Aggregation | | 5 | Aggr | Single-Time Aggregation |
| | | Packet (STAP) | | | | Packet (STAP) |
+-----------+-------------------+--------------------------+ +-----------+-------------------+--------------------------+
| 6 | Aggr | Multi-Time Aggregation | | 6 | Aggr | Multi-Time Aggregation |
| | | Packet (MTAP) | | | | Packet (MTAP) |
+-----------+-------------------+--------------------------+ +-----------+-------------------+--------------------------+
| 7 | Frag | Fragmentation Unit | | 7 | Frag | Fragmentation Unit |
+-----------+-------------------+--------------------------+ +-----------+-------------------+--------------------------+
Table 1: Payload Structure Type for Haptic Table 1: Payload Structure Type for Haptics
The payload structures are represented in Figure 4. The single unit 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.1. The fragmented unit
payload structure is specified in Section 5.3.2. The aggregation payload structure is specified in Section 5.3.2. The aggregation
packet payload structure is specified in Section 5.3.3. The padding packet payload structure is specified in Section 5.3.3. The padding
in the figures of these sections refers to the RTP padding defined in in the figures of these sections refers to the RTP padding defined in
[RFC3550]. [RFC3550].
+-------------------+ +-------------------+
| RTP Header | | RTP Header |
skipping to change at line 440 skipping to change at line 440
Figure 7 describes an FU header, including the following fields: Figure 7 describes an FU header, including the following fields:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|FUS|FUE| RSV | UT | |FUS|FUE| RSV | UT |
+---+---+-----------+-----------+ +---+---+-----------+-----------+
Figure 7: Fragmentation Unit Header Figure 7: Fragmentation Unit Header
FUS (Fragmented Unit Start, 1 bit): This field MUST be set to 1 for FUS (Fragmented Unit Start): 1 bit. This field MUST be set to 1 for
the first fragment and 0 for the other fragments. the first fragment and 0 for the other fragments.
FUE (Fragmented Unit End, 1 bit): This field MUST be set to 1 for FUE (Fragmented Unit End): 1 bit. This field MUST be set to 1 for
the last fragment and 0 for the other fragments. the last fragment and 0 for the other fragments.
The combination FUS=1 and FUE=1 MUST NOT occur; such packets are The combination FUS=1 and FUE=1 MUST NOT occur; such packets are
invalid. invalid.
RSV (Reserved, 3 bits): These bits MUST be set to 0 by the sender RSV (Reserved): 3 bits. These bits MUST be set to 0 by the sender
and ignored by the receiver. and ignored by the receiver.
UT (Unit Type, 3 bits): This field indicates the type of the MIHS UT (Unit Type): 3 bits. This field indicates the type of the MIHS
unit this fragment belongs to, using values defined in Table 1. unit this fragment belongs to, using values defined in Table 1.
The use of MIHS unit fragmentation in RTP means that a media receiver The use of MIHS unit fragmentation in RTP means that a media receiver
can receive some fragments, but not other fragments. The missing can receive some fragments, but not other fragments. The missing
fragments will typically not be retransmitted by RTP. This results fragments will typically not be retransmitted by RTP. This results
in partially received MIHS units, which can be either dropped or used in partially received MIHS units, which can be either dropped or used
by the decoding application, based on implementation. In cases where by the decoding application, based on implementation. In cases where
consecutive fragments with FUE and FUS are lost, the receiver may be consecutive fragments with FUE and FUS are lost, the receiver may be
able to detect that surrounding fragments belong to a different able to detect that surrounding fragments belong to a different
partially received MIHS unit (e.g., if the UT field holds a different partially received MIHS unit (e.g., if the UT field holds a different
skipping to change at line 570 skipping to change at line 570
originate from a not-sent silent unit or a lost packet, a sender MAY originate from a not-sent silent unit or a lost packet, a sender MAY
send one, or a few, MIHS silent units at the beginning of a haptic 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 silence. If a media receiver receives a MIHS silent unit, the
receiver SHOULD assume that silence is intended until the reception receiver SHOULD assume that silence is intended until the reception
of a non-silent MIHS unit. This can reduce the number of false of a non-silent MIHS unit. This can reduce the number of false
detections of lost RTP packets by the decoder. detections of lost RTP packets by the decoder.
In some multimedia conference scenarios using an RTP video mixer In some multimedia conference scenarios using an RTP video mixer
(e.g., when adding or selecting a new source), it is recommended to (e.g., when adding or selecting a new source), it is recommended to
use Full Intra Request (FIR) feedback messages [RFC5104] with use Full Intra Request (FIR) feedback messages [RFC5104] with
Haptics. The purpose of the FIR message is to cause an encoder to haptics. The purpose of the FIR message is to cause an encoder to
send a decoder refresh point at the earliest opportunity. In the send a decoder refresh point at the earliest opportunity. In the
context of haptics, an appropriate decoder refresh point is an context of haptics, an appropriate decoder refresh point is an
initialization MIHS unit. The initialization MIHS unit point enables initialization MIHS unit. The initialization MIHS unit point enables
a decoder to be reset to a known state and to decode all MIHS units a decoder to be reset to a known state and to decode all MIHS units
following it. following it.
6. Payload Format Parameters 6. Payload Format Parameters
This section describes payload format parameters. Section 6.1 This section describes payload format parameters. Section 6.1
specifies new optional parameters, and Section 6.2 further registers specifies new optional parameters, and Section 6.2 further registers
skipping to change at line 600 skipping to change at line 600
of the SDP parameters indicated in this section are based on the of the SDP parameters indicated in this section are based on the
current version of the MPEG Haptics Coding standard (ISO/IEC current version of the MPEG Haptics Coding standard (ISO/IEC
23090-31:2025) and may be different in future versions of 23090-31:2025) and may be different in future versions of
[ISO.IEC.23090-31]. [ISO.IEC.23090-31].
ver: ver:
This parameter provides the year of the edition and amendment of ISO/ This parameter provides the year of the edition and amendment of ISO/
IEC 23090-31 that this file conforms to, as defined in IEC 23090-31 that this file conforms to, as defined in
[ISO.IEC.23090-31]: MPEG_haptics object.version is a string that may [ISO.IEC.23090-31]: MPEG_haptics object.version is a string that may
hold values such as XXXX or XXXX-Y where XXXX is the year of contain 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 publication and Y is the amendment number, if any. For the initial
(and current) version of the MPEG Haptics Coding standard (ISO/IEC (and current) version of the MPEG Haptics Coding standard (ISO/IEC
23090-31:2025), the value is "2025". When ver is not present, a 23090-31:2025), the value is "2025". When ver is not present, a
default value of "2025" SHOULD be inferred. default value of "2025" SHOULD be inferred.
profile: This parameter indicates the profile used to generate the profile: This parameter indicates the profile used to generate the
encoded stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics encoded stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics
object.profile is a string that may hold the values "simple- object.profile is a string that may contain the value "simple-
parametric" or "main". When profile is not present, the default parametric" or "main". When profile is not present, the default
value "main" SHOULD be inferred. value "main" SHOULD be inferred.
lvl: This parameter indicates the level used to generate the encoded lvl: This parameter indicates the level used to generate the encoded
stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics
object.level is an integer that may hold the values 1 or 2. When object.level is an integer that may contain the value 1 or 2.
lvl is not present, the default value 2 SHOULD be inferred. When lvl is not present, the default value 2 SHOULD be inferred.
maxlod: This parameter indicates the maximum level of details (LODs) maxlod: This parameter indicates the maximum level of details (LODs)
to use for the avatar(s). The avatar LOD is defined in to use for the avatar(s). The avatar LOD is defined in
[ISO.IEC.23090-31]: MPEG_haptics.avatar object.lod is an integer [ISO.IEC.23090-31]: MPEG_haptics.avatar object.lod is an integer
that may hold the value 0 or a positive integer. that may contain the value 0 or a positive integer.
avtypes: This parameter indicates, using a comma-separated list, the avtypes: This parameter indicates, using a comma-separated list, the
types of haptic perception represented by the avatar(s). The types of haptic perception represented by the avatar(s). The
avatar type is defined in [ISO.IEC.23090-31]: MPEG_haptics.avatar avatar type is defined in [ISO.IEC.23090-31]: MPEG_haptics.avatar
object.type is a string that may hold values among "Vibration", object.type is a string that may contain the value "Vibration",
"Pressure", "Temperature", or "Custom". "Pressure", "Temperature", or "Custom".
modalities: This parameter indicates, using a comma-separated list, modalities: This parameter indicates, using a comma-separated list,
haptic perception modalities (e.g., pressure, acceleration, haptic perception modalities (e.g., pressure, acceleration,
velocity, position, temperature, etc.). The perception modality velocity, position, temperature, etc.). The perception modality
is defined in [ISO.IEC.23090-31]: MPEG_haptics.perception is defined in [ISO.IEC.23090-31]: MPEG_haptics.perception
object.perception_modality is a string that may hold values among object.perception_modality is a string that may contain the value
"Pressure", "Acceleration", "Velocity", "Position", "Temperature", "Pressure", "Acceleration", "Velocity", "Position", "Temperature",
"Vibrotactile", "Water", "Wind", "Force", "Electrotactile", "Vibrotactile", "Water", "Wind", "Force", "Electrotactile",
"Vibrotactile Texture", "Stiffness", "Friction", "Humidity", "Vibrotactile Texture", "Stiffness", "Friction", "Humidity",
"User-defined Temporal", "User-defined Spatial", or "Other". "User-defined Temporal", "User-defined Spatial", or "Other".
bodypartmask: This parameter is an integer that indicates, using a bodypartmask: This parameter is an integer that indicates, using a
bitmask, the location of the devices or actuators on the body. bitmask, the location of the devices or actuators on the body.
The body part mask is defined in [ISO.IEC.23090-31]: The body part mask is defined in [ISO.IEC.23090-31]:
MPEG_haptics.reference_device object.body_part_mask is a 32-bit MPEG_haptics.reference_device object.body_part_mask is a 32-bit
integer that may hold a bit mask using bit positions defined in integer that may hold a bit mask using bit positions defined in
skipping to change at line 658 skipping to change at line 658
MPEG_haptics.reference_device object.maximum_frequency. MPEG_haptics.reference_device object.maximum_frequency.
minfreq: This parameter is an integer that indicates the minimum minfreq: This parameter is an integer that indicates the minimum
frequency of haptic data for vibrotactile perceptions (Hz). frequency of haptic data for vibrotactile perceptions (Hz).
Minimum frequency is defined in [ISO.IEC.23090-31]: Minimum frequency is defined in [ISO.IEC.23090-31]:
MPEG_haptics.reference_device object.minimum_frequency. MPEG_haptics.reference_device object.minimum_frequency.
dvctypes: This parameter is an integer that indicates, using a dvctypes: This parameter is an integer that indicates, using a
comma-separated list, the types of actuators. The device type is comma-separated list, the types of actuators. The device type is
defined in [ISO.IEC.23090-31]: MPEG_haptics.reference_device defined in [ISO.IEC.23090-31]: MPEG_haptics.reference_device
object.type is a string that may hold values among "LRA", "VCA", object.type is a string that may contain the value "LRA", "VCA",
"ERM", "Piezo", or "Unknown". "ERM", "Piezo", or "Unknown".
silencesupp: This parameter is an integer that indicates whether silencesupp: This parameter is an integer that indicates whether
silence suppression should be used (value 1) or not (value 0). silence suppression should be used (value 1) or not (value 0).
When silencesupp is not present, the default value 0 SHOULD be When silencesupp is not present, the default value 0 SHOULD be
inferred. inferred.
6.2. SDP Parameter Registration 6.2. SDP Parameter Registration
This memo registers a 'haptics' token in the media subregistry of the This memo registers a 'haptics' token in the media subregistry of the
skipping to change at line 759 skipping to change at line 759
level. A receiver supporting a given version will accept a stream level. A receiver supporting a given version will accept a stream
corresponding to the same version and MAY accept other versions. A 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 receiver MAY ignore any part of a received stream, e.g., that it does
not have support for rendering. not have support for rendering.
The haptic signal can be sampled at different rates. The MPEG The haptic signal can be sampled at different rates. The MPEG
Haptics Coding standard does not mandate a specific frequency. A Haptics Coding standard does not mandate a specific frequency. A
typical sample rate is 8000Hz. typical sample rate is 8000Hz.
The parameter 'ver' indicates the version of the haptic standard The parameter 'ver' indicates the version of the haptic standard
specification. If it is not specified, the parameter 'ver' indicates specification. If it is not specified, the value "2025" indicating
the version of the haptic standard specification. If it is not the MPEG Haptics Coding standard ISO/IEC 23090-31:2025
specified, the value "2025" indicating the MPEG Haptics Coding [ISO.IEC.23090-31] SHOULD be inferred, although the sender and
standard ISO/IEC 23090-31:2025 [ISO.IEC.23090-31] SHOULD be inferred, receiver MAY use a specific value based on an out-of-band agreement.
although the sender and receiver MAY use a specific value based on an The parameter 'profile' is used to restrict the number of tools used
out-of-band agreement. The parameter 'profile' is used to restrict (e.g., the simple-parametric profile enables simpler implementations
the number of tools used (e.g., the simple-parametric profile enables than the main profile). If it is not specified, the most general
simpler implementations than the main profile). If it is not profile "main" SHOULD be inferred, although the sender and receiver
specified, the most general profile "main" SHOULD be inferred, MAY use a specific value based on an out-of-band agreement. The
although the sender and receiver MAY use a specific value based on an parameter 'lvl' is used to further characterize implementations
out-of-band agreement. The parameter 'lvl' is used to further within a given profile, e.g., according to the maximum supported
characterize implementations within a given profile, e.g., according number of channels, bands, and perceptions. If it is not specified,
to the maximum supported number of channels, bands, and perceptions. the most general level "2" SHOULD be inferred, although the sender
If it is not specified, the most general level "2" SHOULD be and receiver MAY use a specific version based on an out-of-band
inferred, although the sender and receiver MAY use a specific version agreement.
based on an out-of-band agreement.
Other parameters can be used to indicate bitstream properties as well Other parameters can be used to indicate bitstream properties as well
as receiver capabilities. The parameters 'maxlod', 'avtypes', as receiver capabilities. The parameters 'maxlod', 'avtypes',
'bodypartmask', 'maxfreq', 'minfreq', 'dvctypes', and 'modalities' 'bodypartmask', 'maxfreq', 'minfreq', 'dvctypes', and 'modalities'
can be sent by a sender to reflect the characteristics of bitstreams 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 and can be set by a receiver to reflect the nature and capabilities
of local actuator devices or a preferred set of bitstream properties. of local actuator devices or a preferred set of bitstream properties.
For example, different receivers MAY have different sets of local For example, different receivers MAY have different sets of local
actuators, in which case these parameters can be used to select a actuators, in which case these parameters can be used to select a
stream adapted to the receiver. In some other cases, some receivers stream adapted to the receiver. In some other cases, some receivers
MAY indicate a preference for a set of bitstream properties such as MAY indicate a preference for a set of bitstream properties such as
perceptions, min/max frequency, or body-part-mask, which contribute perceptions, min/max frequency, or body part mask, which contribute
the most to the user experience for a given application, in which the most to the user experience for a given application, in which
case these parameters can be used to select a stream that includes case these parameters can be used to select a stream that includes
and possibly prioritizes those properties. For example, if the and possibly prioritizes those properties. For example, if the
haptic stream server provides more information than the body mask haptic stream server provides more information than the body mask
specified by the receiver, the additional information can be either specified by the receiver, the additional information can be either
integrated into a single effect or ignored by the receiver. integrated into a single effect or ignored by the receiver.
The parameter 'silencesupp' can be used to indicate sender and The parameter 'silencesupp' can be used to indicate sender and
receiver capabilities or preferences. This parameter indicates receiver capabilities or preferences. This parameter indicates
whether silence suppression should be used, as described in whether silence suppression should be used, as described in
skipping to change at line 819 skipping to change at line 818
declare the values used by the bitstream, not the capabilities for declare the values used by the bitstream, not the capabilities for
receiving bitstreams. A receiver of the SDP is required to support receiving bitstreams. A receiver of the SDP is required to support
all parameters and values of the parameters provided; otherwise, the all parameters and values of the parameters provided; otherwise, the
receiver MUST reject or not participate in the session. It falls on 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 the creator of the session to use values that are expected to be
supported by the receiving application. supported by the receiving application.
8. Congestion Control Considerations 8. Congestion Control Considerations
The general congestion control considerations for transporting RTP The general congestion control considerations for transporting RTP
data apply to HMPG haptics over RTP as well [RFC3550]. data apply to MPEG-I haptic data over RTP as well [RFC3550].
It is possible to adapt network bandwidth usage by adjusting either It is possible to adapt network bandwidth usage by adjusting either
the encoder bit rate or the stream content (e.g., the LOD, body the encoder bit rate or the stream content (e.g., the LOD, body
parts, actuator frequency range, target device types, and parts, actuator frequency range, target device types, and
modalities). The considerations in this section are applicable to modalities). The considerations in this section are applicable to
best-effort networks and controlled environments. best-effort networks and controlled environments.
In case of congestion, a receiver or intermediate node MAY prioritize In case of congestion, a receiver or intermediate node MAY prioritize
independent packets over dependent ones, since the non-reception of independent packets over dependent ones, since the non-reception of
an independent MIHS unit can prevent the decoding of multiple an independent MIHS unit can prevent the decoding of multiple
subsequent dependent MIHS units. In case of congestion, a receiver subsequent dependent MIHS units. In case of congestion, a receiver
or intermediate node MAY prioritize initialization MIHS units over or intermediate node MAY prioritize initialization MIHS units over
other units, since initialization MIHS units contain metadata used to other units, as these contain metadata that is used to reinitialize
reinitialize the decoder, and MAY drop silent MIHS units before other the decoder. Additionally, a receiver or intermediate node MAY drop
types of MIHS units, since a receiver MAY interpret a missing MIHS silent units before other types, as a receiver MAY interpret a
unit as a silence. It is also possible, using the layer field of the missing unit as silence. It is also possible, using the layer field
RTP payload header, to allocate MIHS units to different layers based of the RTP payload header, to allocate MIHS units to different layers
on their content to prioritize haptic data that contributes the most based on their content to prioritize haptic data that contributes the
to the user experience. In case of congestion, intermediate nodes most to the user experience. In case of congestion, intermediate
and receivers SHOULD use the MIHS layer value to determine the nodes and receivers SHOULD use the MIHS layer value to determine the
relative importance of haptic RTP packets. relative importance of haptic RTP packets.
Receivers should monitor timestamps and treat gaps as loss of the Receivers should monitor timestamps and treat gaps as loss of the
corresponding MIHS units. MIHS units, as defined in corresponding MIHS units. MIHS units, as defined in
[ISO.IEC.23090-31], should be checked for structural integrity [ISO.IEC.23090-31], should be checked for structural integrity
according to their type. When CRC16 or CRC32 information is present according to their type. When CRC16 or CRC32 information is present
in MIHS units, receivers must validate data integrity, and units in MIHS units, receivers must validate data integrity, and units
failing Cyclic Redundancy Checks (CRCs) should be treated as lost. failing Cyclic Redundancy Checks (CRCs) should be treated as lost.
Receivers should further monitor indicators of service degradation Receivers should further monitor indicators of service degradation
such as unexpected silent gaps, repeated decoder reinitializations, such as unexpected silent gaps, repeated decoder reinitializations,
skipping to change at line 901 skipping to change at line 900
application developer. They can find guidance on available security application developer. They can find guidance on available security
mechanisms and important considerations in "Options for Securing RTP mechanisms and important considerations in "Options for Securing RTP
Sessions" [RFC7201], although [RFC7201] is now considered dated and Sessions" [RFC7201], although [RFC7201] is now considered dated and
several mechanisms described therein have since evolved. several mechanisms described therein have since evolved.
Applications SHOULD use appropriate and current strong security Applications SHOULD use appropriate and current strong security
mechanisms. For modern best practices, applications can consider the mechanisms. For modern best practices, applications can consider the
following options: following options:
* (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS, * (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS,
applications should refer to BCP 195, including [RFC9325], which applications should refer to [BCP195], which provides up-to-date
provides up-to-date recommendations. recommendations.
* IPsec-based protection: Relevant and current protocol * IPsec-based protection: Relevant and current protocol
specifications include [RFC4303] ("IP Encapsulating Security specifications include [RFC4303] ("IP Encapsulating Security
Payload (ESP)") and [RFC7296] ("Internet Key Exchange Protocol Payload (ESP)") and [RFC7296] ("Internet Key Exchange Protocol
Version 2 (IKEv2)"). Version 2 (IKEv2)").
This document does not mandate a specific security mechanism. This document does not mandate a specific security mechanism.
Instead, applications are responsible for selecting mechanisms that Instead, applications are responsible for selecting mechanisms that
follow current best practices for confidentiality, integrity, and follow current best practices for confidentiality, integrity, and
source authentication and that reflect the evolving security source authentication and that reflect the evolving security
skipping to change at line 1020 skipping to change at line 1019
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
[RFC9695] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-Level [RFC9695] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-Level
Media Type", RFC 9695, DOI 10.17487/RFC9695, March 2025, Media Type", RFC 9695, DOI 10.17487/RFC9695, March 2025,
<https://www.rfc-editor.org/info/rfc9695>. <https://www.rfc-editor.org/info/rfc9695>.
11.2. Informative References 11.2. Informative References
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, Payload Format Specifications", BCP 36, RFC 2736,
DOI 10.17487/RFC2736, December 1999, DOI 10.17487/RFC2736, December 1999,
<https://www.rfc-editor.org/info/rfc2736>. <https://www.rfc-editor.org/info/rfc2736>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
skipping to change at line 1073 skipping to change at line 1086
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", [RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017, RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>. <https://www.rfc-editor.org/info/rfc8088>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
Acknowledgments Acknowledgments
Thanks to Philippe Guillotel, Quentin Galvane, Jonathan Lennox, Thanks to Philippe Guillotel, Quentin Galvane, Jonathan Lennox,
Marius Kleidl, and Stephan Wenger for the comments and discussions Marius Kleidl, and Stephan Wenger for the comments and discussions
about this document. about this document.
Authors' Addresses Authors' Addresses
Hyunsik Yang Hyunsik Yang
InterDigital InterDigital
 End of changes. 27 change blocks. 
55 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.48.