[要約] RFC 9993は、MPEG-I触覚データ（MIHS）をリアルタイム転送プロトコル（RTP）で伝送するためのペイロードフォーマットを規定する文書です。RTPパケットへのカプセル化やフラグメンテーションのヘッダー形式を定義し、RFC 9695およびメディアタイプの登録を更新してオプションパラメータやSDP使用方法を追加しています。
Internet Engineering Task Force (IETF) HS Yang
Request for Comments: 9993 X. de Foy
Updates: 9695 InterDigital
Category: Standards Track May 2026
ISSN: 2070-1721
This memo specifies an RTP payload format for MPEG-I haptic data. A haptic media stream is composed of MPEG-I Haptic Stream (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. The original subtype registration for 'haptics/hmpg' (RFC 9695) did not include any required or optional parameters. This memo updates RFC 9695 and the 'haptics/hmpg' registration to add optional parameters. It also provides Session Description Protocol (SDP) usage information for the 'haptics' media type.
このメモは、MPEG-I 触覚データの RTP ペイロード形式を指定します。ハプティック メディア ストリームは、MIHS ユニット ヘッダーと 0 個以上の MIHS パケットを含む MPEG-I ハプティック ストリーム (MIHS) ユニットで構成されます。RTP ペイロード ヘッダー形式により、RTP パケット ペイロード内の MIHS ユニットのパケット化と、MIHS ユニットの複数の RTP パケットへのフラグメンテーションが可能になります。「haptics/hmpg」(RFC 9695) の元のサブタイプ登録には、必須またはオプションのパラメーターが含まれていませんでした。このメモは、RFC 9695 と「haptics/hmpg」登録を更新して、オプションのパラメーターを追加します。また、「ハプティクス」メディア タイプのセッション記述プロトコル (SDP) の使用情報も提供します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9993.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9993 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. Definitions
4. Haptic Format Description
4.1. Overview of Haptic Coding
4.2. MIHS Format
5. Payload Format for Haptics
5.1. RTP Header Usage
5.2. Payload Header
5.3. Payload Structures
5.3.1. Single Unit Payload Structure
5.3.2. Fragmented Unit Payload Structure
5.3.3. Aggregation Packet Payload Structure
5.4. MIHS Units Transmission and Reception Considerations
6. Payload Format Parameters
6.1. Optional Parameters Definition
6.2. SDP Parameter Registration
7. SDP Considerations
7.1. SDP Offer/Answer Considerations
7.2. Declarative SDP Considerations
8. Congestion Control Considerations
9. Security Considerations
10. IANA Considerations
10.1. Media Type Registration Update
10.2. New SDP Parameters Media Registration
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
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, providing them with information to operate according to the values defined in haptic effects. The IETF registered 'haptics' as a primary media type, akin to 'audio' and 'video' [RFC9695].
ハプティクスは、オーディオやビデオに加えて触覚効果をユーザーに提供し、感覚的な没入感を体験できるようにします。触覚データは主にアクチュエーターとして機能するデバイスに送信され、触覚効果で定義された値に従って動作するための情報をデバイスに提供します。IETF は、「オーディオ」や「ビデオ」[RFC9695] と同様に、「触覚」を主要なメディア タイプとして登録しました。
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. 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 and is similar in essence to the Network Abstraction 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] and [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 considerations for the 'haptics' media type.
MPEG ハプティクス コーディング標準 [ISO.IEC.23090-31] は、ハプティック信号をエンコード、デコード、合成、送信するためのデータ形式、メタデータ、およびコーデック アーキテクチャを定義します。この MPEG 標準内では、触覚メディア ストリームは、MIHS ユニット ヘッダーと 0 個以上の MIHS パケットを含む MIHS ユニットで構成されます。MIHS ユニットはストリーミングに適したパケット化のユニットであり、一部のビデオ仕様で定義されているネットワーク アブストラクション レイヤ (NAL) ユニットと本質的に似ています。この文書は、RTP プロトコルを使用して触覚データ (MIHS ユニット) を送信する方法を指定します。この文書は、RTP ペイロード形式ライターに関する [RFC8088] および [RFC2736] の推奨事項に従います。この文書では、ハプティクスとオーディオ/ビデオ コンポーネント間の同期 (リップ シンク) メカニズムについては規定しません。さらに、この文書では、「触覚」メディア タイプに関連する SDP パラメータと SDP オファー/アンサーの考慮事項を指定します。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the definitions of the MPEG Haptics Coding standard [ISO.IEC.23090-31]. Some of these terms are provided here for convenience.
この文書では、MPEG ハプティクス コーディング標準 [ISO.IEC.23090-31] の定義を使用します。これらの用語の一部は便宜上ここに提供されています。
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.
デバイス上の特定の体の位置にレンダリングされる 1 つ以上のバンドを含む知覚内のコンポーネント。
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.
信号を定義するための帯域のコンポーネント。ハプティック波形または 1 つ以上のハプティック キーフレームで構成されます。
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.
経験、認識、チャンネル、またはバンドに関するグローバルな情報。
MIHS unit:
MIHS単位：
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 Section 4 for details.
MPEG-I Haptic Stream 形式のパケット化の単位。このメモで説明する形式のペイロードの単位として使用されます。詳細についてはセクション 4 を参照してください。
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.
デバイス上でレンダリングされる特定のモダリティに関連付けられた触覚の表現。
Hmpg format:
Hmpg形式：
A binary compressed format for haptics data. Information is stored in a binary form, and data compression is applied on data at the band level. The 'haptics/hmpg' media subtype is registered in [RFC9695] and updated by this memo.
ハプティクス データのバイナリ圧縮形式。情報はバイナリ形式で保存され、データ圧縮はバンド レベルでデータに適用されます。「haptics/hmpg」メディアサブタイプは[RFC9695]に登録され、このメモによって更新されます。
Independent unit:
独立したユニット:
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].
MIHS ユニットは、以前のユニットから独立してデコードできる場合、独立しています。独立ユニットにはタイミング情報が含まれており、[ISO.IEC.23090-31] では「同期ユニット」とも呼ばれます。
Dependent unit:
従属ユニット:
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].
MIHS ユニットは、デコードに以前のユニットが必要な場合に依存します。従属ユニットにはタイミング情報が含まれておらず、[ISO.IEC.23090-31] では「非同期ユニット」とも呼ばれます。
Time-independent effect:
時間に依存しない効果:
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 Section 4.2.
時間に関係なく発生する触覚効果。テクスチャの触覚フィードバックはその代表的な例です。時間に依存しない効果は、セクション 4.2 で定義されているように、空間 MIHS 単位でエンコードされます。
Time-dependent effect:
時間依存の効果:
A haptic effect that varies over time. For example, tactile feedback for vibration and force are time-dependent effects and are encoded in temporal MIHS units, as defined in Section 4.2.
時間の経過とともに変化する触覚効果。たとえば、振動と力の触覚フィードバックは時間依存効果であり、セクション 4.2 で定義されているように時間 MIHS 単位でエンコードされます。
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), and also other less common perceptions, such as the sense of temperature or texture, for example. 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 text-based 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 MIHS format and is a base for the RTP payload format described in this document.
MPEG ハプティクス コーディング規格は、没入型体験を可能にするために、ハプティック信号の効率的な送信とレンダリングの方法を指定します。これは、最も一般的な振動触覚 (振動を知覚する触覚) や運動感覚 (触覚の抵抗または力) を含む、複数のタイプの知覚をサポートします。また、温度や質感の感覚など、その他のあまり一般的ではない知覚もサポートします。また、触覚信号をエンコードするための 2 つのアプローチもサポートしています。1 つは測定データのサンプルに基づく「量子化」アプローチ、もう 1 つは関数の組み合わせを使用して信号が合成される「記述的」アプローチです。量子化データと記述データはどちらも、JSON (.hjif) に基づくテキストベースの交換形式、または配布およびストリーミング用のバイナリ パケット化形式 (.hmpg) でエンコードできます。この最後の形式は MIHS 形式と呼ばれ、このドキュメントで説明する RTP ペイロード形式のベースとなります。
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 levels of packetization: MIHS units and MIHS packets.
MIHS は、触覚データの転送に使用されるストリーム形式です。触覚効果を含む触覚データは、MIHS フォーマットに従ってパケット化され、提供された効果に従って動作するアクチュエータに配信されます。MIHS フォーマットには、MIHS ユニットと MIHS パケットという 2 つのレベルのパケット化があります。
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 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, and its duration is a positive number.
MIHS ユニットは、MIHS ユニット ヘッダーと 0 個以上の MIHS パケットで構成されます。4 種類の MIHS 単位が定義されています。初期化 MIHS ユニットには、タイムスタンプを含む、ハプティック デコーダのリセットと初期化に必要なメタデータを運ぶ MIHS パケットが含まれています。時間的 MIHS ユニットには、時間依存効果を定義する 1 つ以上の MIHS パケットが含まれており、圧力、速度、加速度などのモダリティを提供します。時間単位の継続時間は正の数です。空間 MIHS ユニットには、振動触覚テクスチャ、剛性、摩擦などの時間に依存しない効果を提供する 1 つ以上の MIHS パケットが含まれています。空間単位の継続時間は常にゼロです。サイレント MIHS ユニットは、一定の時間間隔中に影響がなく、その期間が正の数であることを示します。
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.
MIHS ユニットは、独立または依存としてマークできます。デコーダが独立したユニットを処理すると、以前の効果がリセットされるため、以前の MIHS ユニットから独立した触覚体験が提供されます。依存ユニットは以前の MIHS ユニットの継続であり、以前の MIHS ユニットをデコードせずに独立してデコードおよびレンダリングすることはできません。初期化および空間 MIHS ユニットは常に独立したユニットです。時間的およびサイレント MIHS ユニットは、依存ユニットまたは独立ユニットにすることができます。
Figure 1 illustrates a succession of MIHS units in a MIHS stream.
図 1 は、MIHS ストリーム内の一連の MIHS ユニットを示しています。
+--------+ +-------+ +-------------+ +-------------+ +-----------+
|Initial*| |Spatial| |Temporal Unit| |Temporal Unit| |Silent Unit|
| Unit |-| Unit |-| (indep.) |-| (dependent) |-| (indep.) |
+--------+ +-------+ +-------------+ +-------------+ +-----------+
*Initialization
Figure 1: Example of MIHS Stream
図 1: MIHS ストリームの例
The RTP header is defined in [RFC3550] and represented in Figure 2. Unless contextualized below, the meaning of the fields depicted in Figure 2 is the same as in Section 5.1 of [RFC3550].
RTP ヘッダーは [RFC3550] で定義され、図 2 に表されます。以下で説明しない限り、図 2 に示されているフィールドの意味は、[RFC3550] のセクション 5.1 にあるものと同じです。
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 (TS) |
+---------------------------------------------------------------+
| Synchronization Source (SSRC) Identifier |
+---------------------------------------------------------------+
| Contributing Source (CSRC) Identifiers |
| .... |
+---------------------------------------------------------------+
Figure 2: RTP Header for Haptics
図 2: ハプティクス用の RTP ヘッダー
Marker bit (M):
マーカービット(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.
1ビット。マーカービットは、触覚沈黙期間後の最初の非沈黙RTPパケット内で1に設定されるべきである(SHOULD)。これにより、エンド ユーザーのエクスペリエンスの品質への影響を最小限に抑えながら、バーストの開始前にジッター バッファーの適応とハプティクス デバイスのウォッシュアウト (つまり、ニュートラル位置へのリセット) が可能になります。他のすべてのパケットのマーカー ビットは 0 に設定しなければなりません (MUST)。
Timestamp (TS):
タイムスタンプ (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).
32ビット。RTP ペイロード内の MIHS ユニットの最初のサンプルのサンプリング時間を表すタイムスタンプ。クロック周波数は、エンコードされた触覚データのサンプルレートに設定されなければならず、帯域外で（たとえば、SDP パラメータとして）伝達されます。
The RTP payload header follows the RTP header. Figure 3 describes the RTP payload header for haptics.
RTP ペイロード ヘッダーは RTP ヘッダーの後に続きます。図 3 は、ハプティクス用の RTP ペイロード ヘッダーを示しています。
+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|D| UT | L |
+-+-----+-------+
Figure 3: RTP Payload Header for Haptics
図 3: ハプティクス用の RTP ペイロード ヘッダー
D (Dependency):
D (依存関係):
1 bit. This field indicates whether the MIHS unit included in the RTP payload is dependent (when its value is one) or independent (when its value is zero).
1ビット。このフィールドは、RTP ペイロードに含まれる MIHS ユニットが依存している (値が 1 の場合) か、独立している (値が 0 の場合) かを示します。
UT (Unit Type):
UT（ユニットタイプ）：
3 bits. This field indicates the type of the MIHS unit included in the RTP payload. UT field values are listed in Table 1.
3ビット。このフィールドは、RTP ペイロードに含まれる MIHS ユニットのタイプを示します。UT フィールドの値を表 1 に示します。
L (MIHS Layer):
L (MIHS 層):
4 bits. This field is an integer value 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 semantics 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'.
4ビット。このフィールドは、アプリケーション固有のニーズに基づいてハプティック送信側 (たとえばハプティック コーデック) によって決定される、RTP ペイロードに含まれる MIHS ユニットの優先順位を示す整数値です。たとえば、送信者は MIHS 層を使用して、エンドユーザー エクスペリエンスに最も大きな影響を与える認識に優先順位を付けることができます。ゼロは最高の優先順位に対応します。個々の MIHS レイヤのセマンティクスは指定されておらず、アプリケーションが割り当てるように残されています。送信者がＭＩＨＳユニットの優先順位を示すためにＬフィールドを使用しない場合、Ｌ値は「０」である。
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 Table 1, identifies both the payload structure and, in the case of a single-unit structure, the type of MIHS unit present in the payload.
3 つの異なるタイプの RTP パケット ペイロード構造が指定されています。シングル ユニット パケットには、ペイロードに単一の MIHS ユニットが含まれます。フラグメンテーション ユニットには、MIHS ユニットのサブセットが含まれます。アグリゲーション パケットには、ペイロードに複数の MIHS ユニットが含まれています。表 1 に示すように、RTP ペイロード ヘッダーのユニット タイプ (UT) フィールドは、ペイロード構造と、単一ユニット構造の場合はペイロード内に存在する MIHS ユニットのタイプの両方を識別します。
+===========+===================+==========================+
| Unit Type | Payload Structure | Packet Type Name |
+===========+===================+==========================+
| 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 |
+-----------+-------------------+--------------------------+
Table 1: Payload Structure Type for Haptics
表 1: ハプティクスのペイロード構造タイプ
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. The aggregation 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 [RFC3550].
ペイロード構造は図 4 に示されています。単一ユニットのペイロード構造はセクション 5.3.1 で指定されています。断片化されたユニットのペイロード構造はセクション 5.3.2 で指定されます。集約パケットのペイロード構造はセクション 5.3.3 で規定されています。これらのセクションの図のパディングは、[RFC3550] で定義されている RTP パディングを指します。
+-------------------+
| RTP Header |
+-------------------+
| RTP Payload Header|
+-------------------+ | (UT = Aggr) |
| RTP Header | +-------------------+
+-------------------+ +-------------------+ | MIHS Unit 1 Size |
| RTP Header | | RTP Payload Header| +-------------------+
+-------------------+ | (UT = Frag) | | MIHS Unit 1 |
| RTP Payload Header| +-------------------+ +-------------------+
+-------------------+ | FU Header | | MIHS Unit 2 Size |
| RTP Payload | +-------------------+ +-------------------+
| (Single MIHS unit)| | RTP Payload | | ... |
+-------------------+ +-------------------+ +-------------------+
(a) single unit (b)fragmentation unit (c) aggregation packet
Figure 4: RTP Transmission Modes
図 4: RTP 送信モード
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].
図 5 に示すように、単一ユニットのペイロード構造では、RTP パケットには RTP ヘッダーが含まれ、その後にペイロード ヘッダーと 1 つの単一 MIHS ユニットが続きます。ペイロード ヘッダーは、セクション 5.2 で説明されている構造に従います。ペイロードには、[ISO.IEC.23090-31] で定義されている MIHS ユニットが含まれています。
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 5: Single Unit Payload Structure
図 5: 単一ユニットのペイロード構造
In a fragmented unit payload structure, as described in Figure 6, 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 7. In the case of fragmentation, all RTP payload header fields MUST remain unchanged across all fragments.
図 6 に示すように、フラグメント化されたユニットのペイロード構造では、RTP パケットには RTP ヘッダー、その後にペイロード ヘッダー、フラグメント ユニット (FU) ヘッダー、および MIHS ユニット フラグメントが含まれます。ペイロード ヘッダーは、セクション 5.2 で説明されている構造に従います。ペイロード ヘッダーの UT フィールドの値は 7 です。FU ヘッダーは、図 7 で説明した構造に従います。フラグメント化の場合、すべての RTP ペイロード ヘッダー フィールドは、すべてのフラグメントにわたって変更されないままでなければなりません (MUST)。
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 6: Fragmentation Unit Payload Structure
図 6: 断片化ユニットのペイロード構造
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.
FU ヘッダーは、単一の MIHS ユニットを複数の RTP パケットにフラグメント化できるようにするために使用されます。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).FU はネストしてはなりません。つまり、FU に別の FU のサブセットを含めてはなりません。
Figure 7 describes an FU header, including the following fields:
図 7 は、次のフィールドを含む FU ヘッダーを示しています。
+---+---+---+---+---+---+---+---+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+---+---+---+---+---+---+---+---+
|FUS|FUE| RSV | UT |
+---+---+-----------+-----------+
Figure 7: Fragmentation Unit Header
図 7: 断片化ユニットのヘッダー
FUS (Fragmented Unit Start):
FUS (断片化されたユニットの開始):
1 bit. This field MUST be set to 1 for the first fragment and 0 for the other fragments.
1ビット。このフィールドは、最初のフラグメントについては 1 に設定し、他のフラグメントについては 0 に設定しなければなりません。
FUE (Fragmented Unit End):
FUE (断片化されたユニットの終了):
1 bit. This field MUST be set to 1 for the last fragment and 0 for the other fragments.
1ビット。このフィールドは、最後のフラグメントの場合は 1 に設定し、他のフラグメントの場合は 0 に設定しなければなりません。
The combination FUS=1 and FUE=1 MUST NOT occur; such packets are invalid.
FUS=1 と FUE=1 の組み合わせは発生してはなりません。そのようなパケットは無効です。
RSV (Reserved):
RSV (予約済み):
3 bits. These bits MUST be set to 0 by the sender and ignored by the receiver.
3ビット。これらのビットは送信者によって 0 に設定され、受信者によって無視されなければなりません。
UT (Unit Type):
UT（ユニットタイプ）：
3 bits. This field indicates the type of the MIHS unit this fragment belongs to, using values defined in Table 1.
3ビット。このフィールドは、表 1 で定義された値を使用して、このフラグメントが属する MIHS ユニットのタイプを示します。
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 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).
RTP で MIHS ユニットのフラグメンテーションを使用すると、メディア受信機は一部のフラグメントを受信できるが、他のフラグメントは受信できないことを意味します。欠落したフラグメントは通常、RTP によって再送信されません。これにより、MIHS ユニットが部分的に受信されますが、実装に応じて、これをドロップするか、デコード アプリケーションによって使用することができます。ＦＵＥおよびＦＵＳを有する連続したフラグメントが失われた場合、受信機は、周囲のフラグメントが部分的に受信された異なるＭＩＨＳユニットに属していることを検出できる可能性がある（例えば、ＵＴフィールドが異なる値を保持している場合）。
In an aggregation packet, as described in Figure 8, the RTP packet contains an RTP header, followed by a payload header, and (for each aggregated MIHS unit) a MIHS unit size followed by the MIHS unit. The payload header follows the structure described in Section 5.2.
図 8 で説明されているように、集約パケットでは、RTP パケットには RTP ヘッダー、その後にペイロード ヘッダー、および (集約された MIHS ユニットごとに) MIHS ユニット サイズとそれに続く MIHS ユニットが含まれます。ペイロード ヘッダーは、セクション 5.2 で説明されている構造に従います。
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 Payl. Head.| MIHS Unit 1 Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| MIHS Unit 1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIHS Unit 2 Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIHS Unit 2 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 8: Single-Time Aggregation Packet
図 8: 1 回限りの集約パケット
Figure 8 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.
図 8 は、同じタイムスタンプに対応する複数の MIHS ユニットを送信するために使用できるシングルタイム アグリゲーション パケット (STAP) を示しています。たとえば、同じコンテンツに 2 つの周波数が使用される場合、STAP で同時に送信できます。このタイプの触覚データは時間に依存しないため、複数の空間ユニットを STAP で一緒に送信することもできます。MIHS ユニット長フィールド (16 ビット) は、それに続く MIHS ユニットの長さをバイト単位で保持します。ペイロードヘッダーの UT フィールドの値は 5 です。
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 Payl. Head.| MIHS Unit 1 Size | TS Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Offset | |
+-+-+-+-+-+-+-+-+ |
| MIHS Unit 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIHS Unit 2 Size | TS Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIHS Unit 2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |...OPTIONAL RTP Padding |
+-------------------------------+-------------------------------+
Figure 9: Multiple-Time Aggregation Packet
図 9: 複数回の集約パケット
Figure 9 shows a 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 in environments where some delay is acceptable. The value of the UT field of the 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 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.
図 9 は、マルチタイム アグリゲーション パケット (MTAP) を示しています。これは、異なるタイムスタンプを持つ複数の MIHS ユニットを 1 つの RTP パケットで送信するために使用されます。複数時間の集約は、多少の遅延が許容される環境でパケット数を減らすのに役立ちます。ペイロード ヘッダーの UT フィールドの値は 6 です。MIHS ユニット長フィールド (16 ビット) は、それに続く MIHS ユニットの長さをバイト単位で保持します。タイムスタンプ オフセット フィールド (TS オフセット、16 ビット) は MTAP の場合に存在し、(MIHS ユニットの時間 - パケットの RTP タイムスタンプ) の値に設定しなければなりません (MUST)。最古の集約単位のタイムスタンプ オフセットは常にゼロでなければなりません (MUST)。したがって、MTAP の RTP タイムスタンプは、最も早い MIHS 単位時間と同一です。
The following considerations apply for the streaming of MIHS units over RTP.
RTP を介した MIHS ユニットのストリーミングには、次の考慮事項が適用されます。
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) 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 units with lengths that have the appropriate variation.
MIHS 形式では、可変期間単位が有効になり、初期化 MIHS 単位を使用して、後続の非ゼロ期間 MIHS 単位の期間と、この期間の最大変動を宣言します。送信者は、RTP ストリーミングの場合、初期化 MIHS ユニットに一定または変動の少ない (たとえば、プレイアウト バッファよりも低い) 継続時間を設定する必要があります (SHOULD)。これにより、受信機は、ユニットが失われたときを早期に (たとえば、タイマーを使用して) 判断し、デコーダを RTP パケット損失に対してより堅牢にすることができます。送信者が持続時間の変動が大きい MIHS ユニットを送信した場合、受信者は、MIHS ユニットが送信中に失われたかどうかを判断するために、長時間 (例えば、継続時間の変動の上限) 待機する必要があってもよい(MAY)。この動作が許容されるかどうかはアプリケーションに依存し、アプリケーションは適切なバリエーションを持つ長さの MIHS ユニットを生成するようにエンコーダーを構成できます。
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 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.
MIHS フォーマットでは、サイレント MIHS ユニットを使用して触覚的沈黙を信号で伝えます。送信者は、ネットワークリソースを節約するために、サイレントユニットを送信しないことを決定してもよい(MAY)。受信者の観点から見ると、欠落した MIHS ユニットは送信されなかったサイレント ユニットまたは失われたパケットに由来する可能性があるため、送信者は触覚サイレンスの開始時に 1 つまたは少数の MIHS サイレント ユニットを送信してもよい(MAY)。メディア受信機が MIHS サイレントユニットを受信した場合、受信機は、サイレントではない MIHS ユニットを受信するまで、サイレントが意図されていると想定すべきである(SHOULD)。これにより、デコーダによる失われた RTP パケットの誤検出の数を減らすことができます。
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 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 to decode all MIHS units following it.
RTP ビデオ ミキサーを使用する一部のマルチメディア会議シナリオ (新しいソースの追加または選択時など) では、触覚を備えたフル イントラ リクエスト (FIR) フィードバック メッセージ [RFC5104] を使用することが推奨されます。FIR メッセージの目的は、エンコーダにデコーダ リフレッシュ ポイントをできるだけ早い機会に送信させることです。ハプティクスのコンテキストでは、適切なデコーダ リフレッシュ ポイントは初期化 MIHS ユニットです。初期化 MIHS ユニット ポイントにより、デコーダを既知の状態にリセットし、それに続くすべての MIHS ユニットをデコードできるようになります。
This section describes payload format parameters. Section 6.1 specifies new optional parameters, and Section 6.2 further registers a new token in the media subregistry of the "Session Description Protocol (SDP) Parameters" registry group.
このセクションでは、ペイロード形式のパラメーターについて説明します。セクション 6.1 では新しいオプションのパラメーターを指定し、セクション 6.2 ではさらに、「セッション記述プロトコル (SDP) パラメーター」レジストリ グループのメディア サブレジストリに新しいトークンを登録します。
It is optional to include the SDP parameters in this section. Some parameters have a default value 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 Section 7.1. 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].
このセクションに SDP パラメータを含めるかどうかはオプションです。一部のパラメータにはデフォルト値があり、セクション 7.1 で説明されているように、帯域外協定が別の値を示していない限り、そのパラメータが SDP に存在しない場合は、その値を推測しなければなりません (MUST)。このセクションで示される SDP パラメータの値は、MPEG ハプティクス コーディング標準 (ISO/IEC 23090-31:2025) の現在のバージョンに基づいており、[ISO.IEC.23090-31] の将来のバージョンでは異なる可能性があります。
ver:
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 that may 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 (and current) version of the MPEG Haptics Coding standard (ISO/IEC 23090-31:2025), the value is "2025". When ver is not present, a default value of "2025" SHOULD be inferred.
このパラメータは、[ISO.IEC.23090-31] で定義されているように、このファイルが準拠する ISO/IEC 23090-31 の版と修正の年を提供します。 MPEG_haptics object.version は、XXXX または XXXX-Y などの値を含む文字列です。ここで、XXXX は発行年、Y は修正番号 (存在する場合) です。MPEG ハプティクス コーディング標準 (ISO/IEC 23090-31:2025) の初期 (および現在の) バージョンの場合、値は「2025」です。ver が存在しない場合、デフォルト値「2025」が推測されるべきです(SHOULD)。
profile:
プロフィール：
This parameter indicates the profile used to generate the encoded stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics object.profile is a string that may contain the value "simple-parametric" or "main". When profile is not present, the default value "main" SHOULD be inferred.
このパラメータは、[ISO.IEC.23090-31] で定義されているように、エンコードされたストリームの生成に使用されるプロファイルを示します。MPEG_haptics object.profile は、値「simple-parametric」または「main」を含む文字列です。プロファイルが存在しない場合、デフォルト値「main」が推測されるべきです(SHOULD)。
lvl:
lvl:
This parameter indicates the level used to generate the encoded stream, as defined in [ISO.IEC.23090-31]: MPEG_haptics object.level is an integer that may contain the value 1 or 2. When lvl is not present, the default value 2 SHOULD be inferred.
このパラメータは、[ISO.IEC.23090-31] で定義されているように、エンコードされたストリームの生成に使用されるレベルを示します。MPEG_haptics object.level は、値 1 または 2 を含むことができる整数です。lvl が存在しない場合、デフォルト値 2 が推論されるべきです(SHOULD)。
maxlod:
最大ロッド:
This parameter indicates the maximum level of details (LOD) to use for the avatar(s). The avatar LOD is defined in [ISO.IEC.23090-31]: MPEG_haptics.avatar object.lod is an integer that may contain the value 0 or a positive integer.
このパラメータは、アバターに使用する最大詳細レベル (LOD) を示します。アバター LOD は [ISO.IEC.23090-31] で定義されています。MPEG_haptics.avatar object.lod は、値 0 または正の整数を含むことができる整数です。
avtypes:
avtype:
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 that may contain the value "Vibration", "Pressure", "Temperature", or "Custom".
このパラメータは、コンマ区切りのリストを使用して、アバターによって表される触覚知覚のタイプを示します。アバター タイプは [ISO.IEC.23090-31] で定義されています。MPEG_haptics.avatar object.type は、値「Vibration」、「Pressure」、「Temperature」、または「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 that may contain the value "Pressure", "Acceleration", "Velocity", "Position", "Temperature", "Vibrotactile", "Water", "Wind", "Force", "Electrotactile", "Vibrotactile Texture", "Stiffness", "Friction", "Humidity", "User-defined Temporal", "User-defined Spatial", or "Other".
このパラメータは、カンマ区切りのリストを使用して、触覚知覚モダリティ (圧力、加速度、速度、位置、温度など) を示します。知覚モダリティは [ISO.IEC.23090-31] で定義されています。MPEG_haptics.perception object.perception_modality は、値「圧力」、「加速度」、「速度」、「位置」、「温度」、「振動触覚」、「水」、「風」、「力」、「電気触覚」、「振動触覚テクスチャ」、「剛性」、「摩擦」、「湿度」、「ユーザー定義の時間的」、「ユーザー定義の空間」、または「その他」。
bodypartmask:
ボディパーツマスク:
This parameter is an integer 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 that may hold a bit mask using bit positions defined in Table 7 of [ISO.IEC.23090-31].
このパラメータは、ビットマスクを使用して、本体上のデバイスまたはアクチュエータの位置を示す整数です。身体部分マスクは [ISO.IEC.23090-31] で定義されています。MPEG_haptics.reference_device object.body_part_mask は、[ISO.IEC.23090-31] の表 7 で定義されているビット位置を使用してビット マスクを保持できる 32 ビット整数です。
maxfreq:
最大周波数:
This parameter is an integer 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.
このパラメータは、振動触覚知覚の触覚データの最大周波数 (Hz) を示す整数です。最大周波数は [ISO.IEC.23090-31]: MPEG_haptics.reference_device object.maximum_frequency で定義されています。
minfreq:
最小周波数:
This parameter is an integer 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.
このパラメータは、振動触覚知覚の触覚データの最小周波数 (Hz) を示す整数です。最小周波数は [ISO.IEC.23090-31]: MPEG_haptics.reference_device object.minimum_frequency で定義されています。
dvctypes:
dvctype:
This parameter 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 that may contain the value "LRA", "VCA", "ERM", "Piezo", or "Unknown".
このパラメータは、コンマ区切りのリストを使用して、アクチュエータのタイプを示します。デバイス タイプは [ISO.IEC.23090-31] で定義されています。MPEG_haptics.reference_device object.type は、値「LRA」、「VCA」、「ERM」、「Piezo」、または「Unknown」を含む可能性がある文字列です。
silencesupp:
サイレンスサポート:
This parameter is an integer that indicates whether silence suppression should be used (value 1) or not (value 0). When silencesupp is not present, the default value 0 SHOULD be inferred.
このパラメータは、無音抑制を使用するか (値 1)、使用しないか (値 0) を示す整数です。Silencesupp が存在しない場合、デフォルト値 0 が推論されるべきです (SHOULD)。
This memo registers a 'haptics' token in the media subregistry of the "Session Description Protocol (SDP) Parameters" registry group. This registration contains the required information elements outlined in the SDP registration procedure defined in Section 8.2 of [RFC8866].
このメモは、「セッション記述プロトコル (SDP) パラメーター」レジストリ グループのメディア サブレジストリに「ハプティクス」トークンを登録します。この登録には、[RFC8866] のセクション 8.2 で定義されている SDP 登録手順で概説されている必須の情報要素が含まれています。
Contact name:
連絡先名:
Hyunsik Yang
ヤン・ヒョンシク
Contact email address:
連絡先メールアドレス:
hyunsik.yang@interdigital.com
hyunsik.yang@interdigital.com
Name being defined (as it will appear in SDP):
定義されている名前 (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.
セッション記述プロトコルの「ハプティクス」メディア タイプは、コンテンツがタッチ関連の感覚としてレンダリングできるメディア ストリームを記述するために使用されます。メディア サブタイプは、ハプティクス ストリームの特定の形式をさらに記述します。SDP の「ハプティクス」メディア タイプは、ハプティクス メディア ストリームを確立するために使用されます。
Reference:
参照：
RFC 9993
RFC 9993
The mapping of the above-defined payload format media type to the corresponding fields in SDP is done according to [RFC8866].
上記で定義されたペイロード形式メディア タイプの SDP 内の対応するフィールドへのマッピングは、[RFC8866] に従って行われます。
The media name in the "m=" line of SDP MUST be haptics.
SDP の「m=」行のメディア名は haptics でなければなりません。
The encoding name in the "a=rtpmap" line of SDP MUST be hmpg.
SDP の「a=rtpmap」行のエンコーディング名は hmpg でなければなりません。
The clock rate in the "a=rtpmap" line may be any sampling rate, typically 8000.
「a=rtpmap」行のクロック レートは、任意のサンプリング レート (通常は 8000) にすることができます。
The optional parameters (defined in Section 6.1), 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 that are strings are not case sensitive and SHOULD be written in lowercase.
オプションのパラメータ(セクション6.1で定義)が存在する場合、SDPの「a=fmtp」行に含めなければなりません(MUST)。これは、セミコロンで区切られたパラメータ=値のペアのリストの形式でメディア タイプ文字列として表現されます。SDP では、文字列値を含むパラメータ値を引用符 ("") なしで記述する必要があります。文字列であるパラメータ値は大文字と小文字が区別されないため、小文字で記述する必要があります。
An example of media representation corresponding to the hmpg RTP payload in SDP is as follows:
SDP の hmpg RTP ペイロードに対応するメディア表現の例は次のとおりです。
m=haptics 43291 UDP/TLS/RTP/SAVPF 115
a=rtpmap:115 hmpg/8000
a=fmtp:115 profile=main;lvl=1;ver=2025
When using the offer/answer procedure described in [RFC3264] to negotiate the use of haptic, the following considerations apply:
[RFC3264] に記載されているオファー/アンサー手順を使用して触覚の使用を交渉する場合、次の考慮事項が適用されます。
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.
単方向ストリームに使用される場合、SDP パラメータは送信者 (送信側) と受信者 (受信側) のプロパティを表します。sendrecv ストリームに使用される場合、SDP パラメーターは受信側のプロパティを表します。
The receiver properties expressed using the SDP parameters 'ver', '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.
SDP パラメータ「ver」、「profile」、および「lvl」を使用して表現される受信機プロパティは、実装機能に対応します。ver、profile、および lvl パラメータは、SDP オファーとアンサーで対称的に使用する必要があります。つまり、回答内の値は、明示的に通知されたか、暗黙的に推測されたオファー内の値と一致しなければなりません。同じセッション内では、以降のオファーや回答でバージョン、プロファイル、レベルを変更してはなりません。
The properties expressed using SDP parameters other than 'ver', '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.
「ver」、「profile」、および「lvl」以外の SDP パラメーターを使用して表現されるプロパティは、効率的なデータ送信のための推奨事項として提供されており、拘束力はありません。つまり、送信者は受信者によって指定されたパラメーターに準拠することが推奨されますが、必須ではありません。これらのプロパティは、オファーとアンサーで異なる値に設定される場合があります。これらのプロパティは、後続のオファーまたは回答で更新される場合があります。
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 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 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.
[ISO.IEC.23090-31] に準拠する受信機は、互換性のあるバージョン、プロファイル、レベルでストリームをデコードできなければなりません (MUST)。より一般的なプロファイルをサポートする受信機は、同じプロファイルまたはそれほど一般的ではないプロファイルに対応するストリームを受け入れます（たとえば、「メイン」は「シンプルパラメトリック」よりも一般的です）。特定のレベルをサポートする受信機は、同じレベルまたはそれより低いレベルに対応するストリームを受け入れます。特定のバージョンをサポートする受信機は、同じバージョンに対応するストリームを受け入れ、他のバージョンを受け入れてもよい(MAY)。受信者は、受信したストリームのどの部分も無視してもよい(MAY) (レンダリングをサポートしていないなど)。
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 8000 Hz.
触覚信号はさまざまなレートでサンプリングできます。MPEG ハプティクス コーディング規格では、特定の周波数を義務付けていません。一般的なサンプルレートは 8000 Hz です。
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 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.
パラメータ「ver」は、ハプティック標準仕様のバージョンを示します。指定されていない場合、MPEG ハプティクス コーディング標準 ISO/IEC 23090-31:2025 [ISO.IEC.23090-31] を示す値 "2025" が推測されるべきです (SHOULD)。 ただし、送信者と受信者は帯域外協定に基づいて特定の値を使用してもよいです (MAY)。パラメータ「プロファイル」は、使用するツールの数を制限するために使用されます（たとえば、シンプルパラメトリックプロファイルにより、メインプロファイルよりも単純な実装が可能になります）。それが指定されていない場合、送信者と受信者は帯域外協定に基づいて特定の値を使用してもよいが、最も一般的なプロファイル「main」が推論されるべきである(SHOULD)。パラメータ「lvl」は、サポートされるチャネル、帯域、および認識の最大数に従って、特定のプロファイル内の実装をさらに特徴付けるために使用されます。指定されていない場合、最も一般的なレベル「2」が推論される必要がありますが、送信者と受信者は帯域外協定に基づいて特定のバージョンを使用してもよい[MAY]。
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 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 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.
他のパラメータを使用して、ビットストリームのプロパティと受信機の機能を示すことができます。パラメーター「maxlod」、「avtypes」、「bodypartmask」、「maxfreq」、「minfreq」、「dvctypes」、および「modalities」は、ビットストリームの特性を反映するために送信者によって送信でき、ローカル アクチュエーター デバイスの性質と機能、またはビットストリーム プロパティの優先セットを反映するために受信者によって設定できます。たとえば、異なる受信機は異なるローカル アクチュエータのセットを持つことができ、その場合、これらのパラメータを使用して、受信機に適合するストリームを選択できます。他の場合には、一部の受信機は、特定のアプリケーションのユーザーエクスペリエンスに最も貢献する知覚、最小/最大周波数、身体部分マスクなどのビットストリームプロパティのセットに対する優先順位を示すことができます。その場合、これらのパラメータは、それらのプロパティを含むストリームを選択するために使用でき、場合によってはそれらのプロパティを優先することができます。たとえば、触覚ストリーム サーバーが受信機によって指定されたボディ マスクよりも多くの情報を提供する場合、追加情報は単一の効果に統合されるか、受信機によって無視されます。
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 Section 5.4. 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.
パラメータ「silencesupp」は、送信者と受信者の機能または設定を示すために使用できます。このパラメータは、セクション 5.4 で説明されているように、無音抑制を使用するかどうかを示します。それが指定されていない場合、送信者と受信者は帯域外合意に基づいて無音抑制を使用してもよいが、無音抑制がないことを示す値「0」が推定されるべきである(SHOULD)。
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', and '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.
RTP 上の触覚コンテンツが SDP で宣言型スタイルで提供される場合、ビットストリーム プロパティと受信機機能の両方を示すことができるパラメーターは、ビットストリーム プロパティのみを示すために使用されます。たとえば、この場合、パラメータ「maxlod」、「bodypartmask」、「maxfreq」、「minfreq」、「dvctypes」、および「modalities」は、ビットストリームを受信する機能ではなく、ビットストリームによって使用される値を宣言します。SDP の受信者は、提供されたすべてのパラメーターとパラメーターの値をサポートする必要があります。それ以外の場合、受信者はセッションを拒否するか、セッションに参加しなければなりません。受信側アプリケーションによってサポートされることが期待される値を使用するかどうかは、セッションの作成者の責任となります。
The general congestion control considerations for transporting RTP data apply to MPEG-I haptic data over RTP as well [RFC3550].
RTP データを転送するための一般的な輻輳制御の考慮事項は、RTP 上の MPEG-I 触覚データにも同様に適用されます [RFC3550]。
It is possible to adapt network bandwidth usage by adjusting either the encoder bit rate or the stream content (e.g., 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.
エンコーダのビット レートまたはストリーム コンテンツ (LOD、身体部分、アクチュエータ周波数範囲、ターゲット デバイス タイプ、モダリティなど) を調整することで、ネットワーク帯域幅の使用状況を調整することができます。このセクションの考慮事項は、ベストエフォート型のネットワークと制御された環境に適用されます。
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, 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. 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 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.
輻輳の場合、独立 MIHS ユニットを受信しないと後続の複数の依存 MIHS ユニットの復号が妨げられる可能性があるため、受信機または中間ノードは依存パケットよりも独立パケットを優先してもよい (MAY)。輻輳の場合、受信機または中間ノードは、初期化 MIHS ユニットを他のユニットよりも優先してもよい(MAY)。これらのユニットには、デコーダを再初期化するために使用されるメタデータが含まれるためである。さらに、受信者は欠落しているユニットを沈黙として解釈してもよい(MAY)ので、受信者または中間ノードは、他のタイプよりも先に沈黙ユニットをドロップしてもよい(MAY)。また、RTP ペイロード ヘッダーのレイヤー フィールドを使用して、コンテンツに基づいて MIHS ユニットをさまざまなレイヤーに割り当て、ユーザー エクスペリエンスに最も貢献する触覚データを優先することもできます。輻輳の場合、中間ノードと受信機は、MIHS 層の値を使用して、触覚 RTP パケットの相対的な重要性を決定する必要があります (SHOULD)。
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 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].
受信機はタイムスタンプを監視し、ギャップを対応する MIHS ユニットの損失として扱う必要があります。[ISO.IEC.23090-31] で定義されている MIHS ユニットは、そのタイプに応じて構造的完全性をチェックする必要があります。MIHS ユニットに CRC16 または CRC32 情報が存在する場合、受信機はデータの整合性を検証する必要があり、巡回冗長検査 (CRC) に失敗したユニットは失われたものとして扱う必要があります。受信機は、予期しないサイレントギャップ、デコーダの再初期化の繰り返し、またはデコードの失敗などのサービス低下の指標をさらに監視する必要があります。受信者は、RTCP Receiver Reports [RFC3550] を使用してパケット損失を送信者に報告する必要があり、利用可能な場合は、[RFC4585] で説明されているメカニズムを使用して詳細な損失とジッターのメトリクスを報告できます。
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 and threats associated with the use of compression by the codec. Security considerations for threats commonly associated with RTP payload formats are outlined in [RFC3550], as well as in RTP profiles such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], and RTP/ SAVPF [RFC5124].
RTP ペイロード形式は、RTP ペイロード形式に一般的に関連付けられているセキュリティ上の脅威に加え、触覚デバイスと物理世界との相互作用に特有の脅威や、コーデックによる圧縮の使用に関連する脅威にもさらされます。RTP ペイロード形式に一般的に関連する脅威に対するセキュリティ上の考慮事項は、[RFC3550] のほか、RTP/AVP [RFC3551]、RTP/AVPF [RFC4585]、RTP/SAVP [RFC3711]、RTP/SAVPF [RFC5124] などの RTP プロファイルでも概説されています。
Haptic sensors and actuators operate within the physical environment. This introduces the potential for information leakage through sensors or damage to actuators due to data tampering. Additionally, misusing the functionalities of actuators (such as force, position, temperature, vibration, electrotactile, etc.) may pose a risk of harm to the user, for 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, harm can be inflicted by setting values 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 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.
しかし、「RTP フレームワークのセキュリティ: なぜ RTP は単一メディア セキュリティ ソリューションを義務付けないのか」[RFC7202] で説明されているように、RTP 全般の機密性、完全性、ソースの信頼性などの基本的なセキュリティ目標を満たすためにどのようなソリューションが使用されるかを議論したり義務付けたりするのは RTP ペイロード形式の責任ではありません。セキュリティメカニズムを実装する責任はアプリケーション開発者にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「Options for Securing RTP Sessions」[RFC7201] で見つけることができます。ただし、[RFC7201] は現在古いとみなされており、そこに記載されているいくつかのメカニズムはその後進化しています。
Applications SHOULD use appropriate and current strong security mechanisms. For modern best practices, applications can consider the following options:
アプリケーションは、適切で最新の強力なセキュリティ メカニズムを使用する必要があります。最新のベスト プラクティスとして、アプリケーションは次のオプションを検討できます。
* (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS, applications should refer to [BCP195], which provides up-to-date recommendations.
* (D) TLS ベースの保護: TLS 1.3 および DTLS の使用に関するガイダンスについては、アプリケーションは最新の推奨事項を提供する [BCP195] を参照する必要があります。
* IPsec-based protection: Relevant and current protocol specifications include [RFC4303] ("IP Encapsulating Security Payload (ESP)") and [RFC7296] ("Internet Key Exchange Protocol Version 2 (IKEv2)").
* IPsec ベースの保護: 関連する現在のプロトコル仕様には、[RFC4303] (「IP カプセル化セキュリティ ペイロード (ESP)」) および [RFC7296] (「インターネット キー交換プロトコル バージョン 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 and that reflect the evolving security landscape beyond what is covered in [RFC7201].
この文書は、特定のセキュリティ メカニズムを義務付けるものではありません。代わりに、アプリケーションは、機密性、完全性、およびソース認証に関する現在のベスト プラクティスに従い、[RFC7201] でカバーされている内容を超えて進化するセキュリティ状況を反映するメカニズムを選択する責任があります。
The haptic codec used with this payload format uses a compression algorithm (see Sections 8.2.8.5 and 8.3.3.2 in [ISO.IEC.23090-31]). An attacker may inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded, similarly to [RFC3551].
このペイロード形式で使用される触覚コーデックは、圧縮アルゴリズムを使用します ([ISO.IEC.23090-31] のセクション 8.2.8.5 および 8.3.3.2 を参照)。攻撃者は、[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.
認証、整合性、または機密性保護によるエンドツーエンドのセキュリティにより、メディア対応ネットワーク要素 (MANE) が完全なパケットを破棄する以外のメディア対応操作を実行できなくなります。機密保護の場合、メディアを意識した方法でパケットを破棄することも防止されます。このような操作の実行を許可するには、MANE がセキュリティ コンテキストの確立に含まれる信頼できるエンティティである必要があります。
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 defines optional parameters for this type in Section 6.1. The original subtype registration for '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.
このメモは、ISO/IEC 23090-31: ハプティクス コーディング [ISO.IEC.23090-31] で説明されている MPEG-I ハプティクス ストリーミング可能なバイナリ コーディング形式で使用するために、[RFC9695] で定義されている「hmpg」ハプティクス サブタイプを更新します。このメモは、セクション 6.1 でこのタイプのオプションのパラメータを定義します。[RFC9695] で IANA に登録された「haptics/hmpg」の元のサブタイプ登録には、必須またはオプションのパラメーターが含まれていませんでした。このドキュメントでは、下位互換性を維持しながら拡張機能を有効にするためのオプションのパラメーターを紹介します。
A mapping of the parameters into 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.
SDP を使用するアプリケーションには、パラメータの SDP [RFC8866] へのマッピングも提供されます。SDP を使用しない制御プロトコルで使用するために、同等のパラメータを別の場所で定義することもできます。受信者は、このメモで指定されていないパラメータを無視しなければなりません(MUST)。
IANA has updated the registration for 'haptics', described in Section 6.2, in the "haptics" registry within the "Media Types" registry group and listed document as an additional reference.
IANA は、セクション 6.2 で説明されている「メディア タイプ」レジストリ グループ内の「ハプティクス」レジストリ内の「ハプティクス」の登録を更新し、追加の参照としてドキュメントをリストしました。
The following entries identify the updates to the 'haptics/hmpg' registration:
次のエントリは、「haptics/hmpg」登録の更新を識別します。
Type name:
型名:
haptics
ハプティクス
Subtype name:
サブタイプ名:
hmpg
hpg
The following entries are replaced by this memo:
次のエントリはこのメモに置き換えられます。
Optional parameters:
オプションのパラメータ:
See Section 6.1 of RFC 9993
RFC 9993 のセクション 6.1 を参照してください。
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Yeshwant Muthusamy (yeshwant@yeshvik.com) and Hyunsik Yang (hyunsik.yang@interdigital.com)
Yeshwant Muthusamy (yeshwant@yeshvik.com) および Hyunsik Yang (hyunsik.yang@interdigital.com)
IANA has registered the following in the "media" registry within the "Session Description Protocol (SDP) Parameters" registration group.
IANA は、「セッション記述プロトコル (SDP) パラメーター」登録グループ内の「メディア」レジストリに以下を登録しました。
+=======+==========+===========+
| Type | SDP Name | Reference |
+=======+==========+===========+
| media | haptics | RFC 9993 |
+-------+----------+-----------+
Table 2
[ISO.IEC.23090-31]
ISO/IEC, "Information technology - Coded representation of
immersive media - Part 31: Haptics coding", ISO/
IEC 23090-31:2025, 2025,
<https://www.iso.org/standard/86122.html>.
[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/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, July 2002,
<https://www.rfc-editor.org/info/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/info/rfc3550>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/info/rfc8866>.
[RFC9695] Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-Level
Media Type", RFC 9695, DOI 10.17487/RFC9695, March 2025,
<https://www.rfc-editor.org/info/rfc9695>.
[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
Payload Format Specifications", BCP 36, RFC 2736,
DOI 10.17487/RFC2736, December 1999,
<https://www.rfc-editor.org/info/rfc2736>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>.
Thanks to Philippe Guillotel, Quentin Galvane, Jonathan Lennox, Marius Kleidl, and Stephan Wenger for the comments and discussions about this document.
この文書に関するコメントとディスカッションを提供してくれた Philippe Guillotel、Quentin Galvane、Jonathan Lennox、Marius Kleidl、Stephan Wenger に感謝します。
Hyunsik Yang
InterDigital
United States of America
Email: hyunsik.yang@interdigital.com
Xavier de Foy
InterDigital
Canada
Email: xavier.defoy@interdigital.com