7. SDP Considerations
Cette page resume la section correspondante du RFC 9993 et conserve RTP payload, MIHS, SDP et les details IANA.
The SDP mapping, SDP example, offer/answer considerations, and declarative SDP considerations are preserved below.
7. SDP Considerations
The mapping of the above-defined payload format media type to the
corresponding fields in SDP is done according to [RFC8866].
The media name in the "m=" line of SDP MUST be haptics.
The encoding name in the "a=rtpmap" line of SDP MUST be hmpg.
The clock rate in the "a=rtpmap" line may be any sampling rate,
typically 8000.
The optional parameters (defined in Section 6.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.
An example of media representation corresponding to the hmpg RTP
payload in SDP is as follows:
m=haptics 43291 UDP/TLS/RTP/SAVPF 115
a=rtpmap:115 hmpg/8000
a=fmtp:115 profile=main;lvl=1;ver=2025
7.1. SDP Offer/Answer Considerations
When using the offer/answer procedure described in [RFC3264] to
negotiate the use of haptic, the following considerations apply:
When used for a unidirectional stream, the SDP parameters represent
the properties of the sender (on the sending side) and of the
receiver (on the receiving side). When used for a sendrecv stream,
the SDP parameters represent the properties of the receiver.
The receiver properties expressed using the SDP parameters 'ver',
'profile', and 'lvl' correspond to implementation capabilities. The
ver, profile, and lvl parameters MUST be used symmetrically in SDP
offer and answer. That is, their values in the answer MUST match
those in the offer, either explicitly signaled or implicitly
inferred. In the same session, ver, profile, and lvl MUST NOT be
changed in subsequent offers or answers.
The properties expressed using SDP parameters other than 'ver',
'profile', and 'lvl' are provided as recommendations for efficient
data transmission and are not binding, meaning that a sender is
encouraged but not required to conform to the parameters specified by
the receiver. These properties MAY be set to different values in
offers and answers. These properties MAY be updated in subsequent
offers or answers.
Any receiver compliant with [ISO.IEC.23090-31] MUST be capable of
decoding any stream with a compatible version, profile, and level. A
receiver supporting a more general profile will accept a stream
corresponding to 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.
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.
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.
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.
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.
7.2. Declarative SDP Considerations
When haptic content over RTP is offered with SDP in a declarative
style, the parameters capable of indicating both bitstream properties
as well as receiver capabilities are used to indicate only bitstream
properties. For example, in this case, the parameters '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.