RFC 7826
Real-Time Streaming Protocol Version 2.0
21.2. Media Stream Delivery Threats
The fact that RTSP establishes and controls a media-stream delivery results in a set of security issues related to the media streams. This section will attempt to analyze general threats; however, the choice of media-stream transport protocol, such as RTP, will result in some differences in threats and what mechanisms exist to mitigate them. Thus, it becomes important that each specification of a new media-stream transport and delivery protocol usable by RTSP requires its own security analysis. This section includes one for RTP.
The set of general threats from or by the media-stream delivery
itself are:
Concentrated Denial-of-Service Attack: The protocol offers the
opportunity for a remote-controlled DoS attack, where the media
stream is the hammer in that DoS attack. See Section 21.2.1.
Media Confidentiality: The media delivery may contain content of any
type, and it is not possible, in general, to determine how
sensitive this content is from a confidentiality point. Thus, it
is a strong requirement that any media delivery protocol supply a
method for providing confidentiality of the actual media content.
In addition to the media-level confidentiality, it becomes
critical that no resource identifiers used in the signaling be
exposed to an attacker as they may have human-understandable names
or may be available to the attacker, allowing it to determine the
content the user received. Thus, the signaling protocol must also
provide confidentiality protection of any information related to
the media resource.
Media Integrity and Authentication: There are several reasons why an
attacker will be interested in substituting the media stream sent
out from the RTSP server with one of the attacker's creation or
selection, such as discrediting the target and misinformation
about the target. Therefore, it is important that the media
protocol provide mechanisms to verify the source authentication
and integrity and to prevent replay attacks on the media stream.
Scope of Multicast: If RTSP is used to control the transmission of
media onto a multicast network, the scope of the delivery must be
considered. RTSP supports the TTL Transport header parameter to
indicate this scope for IPv4. IPv6 has a different mechanism for
the scope boundary. However, such scope control has risks, as it
may be set too large and distribute media beyond the intended
scope.
Below (Section 21.2.2) a protocol-specific analysis of security
considerations for RTP-based media transport is included. In that
section, the requirements on implementing security functions for RTSP
agents supporting media delivery over RTP are made clear.
21.2.1. Remote DoS Attack
The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in the prevention of more attacks or ascertaining the attacker's identity. Thus, an RTSP server MUST only allow client- specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms. Security mechanisms that are acceptable in order of increasing generality are: o Verification of the client's identity against a database of known users using RTSP authentication mechanisms (preferably Digest authentication or stronger) o A list of addresses that have consented to be media destinations, especially considering user identity o Verification based on media path The server SHOULD NOT allow the destination field to be set unless a mechanism exists in the system to authorize the request originator to direct streams to the recipient. It is preferred that this authorization be performed by the media recipient (destination) itself and the credentials be passed along to the server. However, in certain cases, such as when the recipient address is a multicast group or when the recipient is unable to communicate with the server in an out-of-band manner, this may not be possible. In these cases, the server may choose another method such as a server-resident authorization list to ensure that the request originator has the proper credentials to request stream delivery to the recipient. One solution that performs the necessary verification of acceptance of media suitable for unicast-based delivery is the NAT traversal method based on Interactive Connectivity Establishment (ICE) [RFC5245] described in [RFC7825]. This mechanism uses random passwords and a username so that the probability of unintended indication as a valid media destination is very low. In addition, the server includes in its Session Traversal Utilities for NAT (STUN) [RFC5389] requests a cookie (consisting of random material) that the destination echoes back; thus, the solution also safeguards against having an off-path attacker being able to spoof the STUN checks. This leaves this solution vulnerable only to on-path attackers that can see the STUN requests go to the target of attack and thus forge a response.
For delivery to multicast addresses, there is a need for another solution that is not specified in this memo.21.2.2. RTP Security Analysis
RTP is a commonly used media-transport protocol and has been the most common choice for RTSP 1.0 implementations. The core RTP protocol has been in use for a long time, and it has well-known security properties and the RTP security consideration (Section 9 of [RFC3550]) needs to be reviewed. In perspective of the usage of RTP in the context of RTSP, the following properties should be noted: Stream Additions: RTP has support for multiple simultaneous media streams in each RTP session. As some use cases require support for non-synchronized adding and removal of media streams and their identifiers, an attacker can easily insert additional media streams into a session context that, according to protocol design, is intended to be played out. Another threat vector is one of DoS by exhausting the resources of the RTP session receiver, for example, by using a large number of SSRC identifiers simultaneously. The strong mitigation of this is to ensure that one cryptographically authenticates any incoming packet flow to the RTP session. Weak mitigations like blocking additional media streams in session contexts easily lead to a DoS vulnerability in addition to preventing certain RTP extensions or use cases that rely on multiple media streams, such as RTP retransmission [RFC4588] to function. Forged Feedback: The built-in RTCP also offers a large attack surface for a couple of different types of attacks. One venue is to send RTCP feedback to the media sender indicating large amounts of packet loss and thus trigger a media bitrate adaptation response from the sender resulting in lowered media quality and potentially a shutdown of the media stream. Another attack is to perform a resource-exhaustion attack on the receiver by using many SSRC identifiers to create large state tables and increase the RTCP-related processing demands. RTP/RTCP Extensions: RTP and RTCP extensions generally provide additional and sometimes extremely powerful tools for DoS attacks or service disruption. For example, the Code Control Message [RFC5104] RTCP extensions enables both the lock down of the bitrate to low values and disruption of video quality by requesting intra-frames. Taking into account the above general discussion in Section 21.2 and the RTP-specific discussion in this section, it is clear that it is necessary that a strong security mechanism be supported to protect
RTP. Therefore, this specification has the following requirements on RTP security functions for all RTSP agents that handle media streams and where media-stream transport is completed using RTP. RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and, thus, SAVP. In addition, SAVPF [RFC5124] MUST also be supported if AVPF is implemented. This specification requires no additional cryptographic transforms or configuration values beyond those specified as mandatory to implement in RFC 3711, i.e., AES-CM and HMAC-SHA1. The default key-management mechanism that MUST be implemented is the one defined in MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY implementation MUST implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and the SRTP parameter negotiation necessary to negotiate the supported SRTP transforms and parameters.22. IANA Considerations
This section describes a number of registries for RTSP 2.0 that have been established and are maintained by IANA. These registries are separate from any registries existing for RTSP 1.0. For each registry, there is a description of the required content, the registration procedures, and the entries that this document registers. For more information on extending RTSP, see Section 2.7. In addition, this document registers three SDP attributes. Registries or entries in registries that have been made for RTSP 1.0 are not moved to RTSP 2.0: the registries and entries of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry in a registry is also required in RTSP 2.0, it MUST follow the procedure defined below to allocate the registry or entry in a registry. The sections describing how to register an item use some of the registration policies described in [RFC5226] -- namely, "First Come First Served", "Expert Review", "Specification Required", and "Standards Action". In case a registry requires a contact person, the authors (with Magnus Westerlund <magnus.westerlund@ericsson.com> as primary) are the contact persons for any entries created by this document. IANA will request the following information for any registration request: o A name of the item to register according to the rules specified by the intended registry
o Indication of who has change control over the feature (for
example, the IETF, ISO, ITU-T, other international standardization
bodies, a consortium, a particular company or group of companies,
or an individual)
o A reference to a further description, if available, for example
(in decreasing order of preference), an RFC, a published standard,
a published paper, a patent filing, a technical report, documented
source code or a computer manual
o For proprietary features, contact information (postal and email
address)
22.1. Feature Tags
22.1.1. Description
When a client and server try to determine what part and functionality
of the RTSP specification and any future extensions that its
counterpart implements, there is need for a namespace. This registry
contains named entries representing certain functionality.
The usage of feature tags is explained in Section 11 and
Section 13.1.
22.1.2. Registering New Feature Tags with IANA
The registering of feature tags is done on a First Come, First Served
[RFC5226] basis.
The registry entry for a feature tag has the following information:
o The name of the feature tag
* If the registrant indicates that the feature is proprietary,
IANA should request a vendor "prefix" portion of the name. The
name will then be the vendor prefix followed by a "." followed
by the rest of the provided feature name.
* If the feature is not proprietary, then IANA need not collect a
prefix for the name.
o A one-paragraph description of what the feature tag represents
o The applicability (server, client, proxy, or some combination)
o A reference to a specification, if applicable
Feature tag names (including the vendor prefix) may contain any non-
space and non-control characters. There is no length limit on
feature tags.
Examples for a vendor tag describing a proprietary feature are:
vendorA.specfeat01
vendorA.specfeat02
22.1.3. Registered Entries
The following feature tags are defined in this specification and
hereby registered. The change control belongs to the IETF.
play.basic: The implementation for delivery and playback operations
according to the core RTSP specification, as defined in this
memo. Applies for clients, servers, and proxies. See
Section 11.1.
play.scale: Support of scale operations for media playback. Applies
only for servers. See Section 18.46.
play.speed: Support of the speed functionality for media delivery.
Applies only for servers. See Section 18.50.
setup.rtp.rtcp.mux: Support of the RTP and RTCP multiplexing as
discussed in Appendix C.1.6.4. Applies for both client and
servers and any media caching proxy.
The IANA registry is a table with the name, description, and
reference for each feature tag.
22.2. RTSP Methods
22.2.1. Description
Methods are described in Section 13. Extending the protocol with new
methods allows for totally new functionality.
22.2.2. Registering New Methods with IANA
A new method is registered through a Standards Action [RFC5226]
because new methods may radically change the protocol's behavior and
purpose.
A specification for a new RTSP method consists of the following
items:
o A method name that follows the ABNF rules for methods.
o A clear specification of what a request using the method does and
what responses are expected. In which directions the method is
used: C->S, S->C, or both. How the use of headers, if any,
modifies the behavior and effect of the method.
o A list or table specifying which of the IANA-registered headers
that are allowed to be used with the method in the request or/and
response. The list or table SHOULD follow the format of tables in
Section 18.
o Describe how the method relates to network proxies.
22.2.3. Registered Entries
This specification, RFC 7826, registers 10 methods: DESCRIBE,
GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP,
SET_PARAMETER, and TEARDOWN. The initial table of the registry is
provided below.
Method Directionality Reference
-----------------------------------------------------
DESCRIBE C->S RFC 7826
GET_PARAMETER C->S, S->C RFC 7826
OPTIONS C->S, S->C RFC 7826
PAUSE C->S RFC 7826
PLAY C->S RFC 7826
PLAY_NOTIFY S->C RFC 7826
REDIRECT S->C RFC 7826
SETUP C->S RFC 7826
SET_PARAMETER C->S, S->C RFC 7826
TEARDOWN C->S, S->C RFC 7826
22.3. RTSP Status Codes
22.3.1. Description
A status code is the three-digit number used to convey information in
RTSP response messages; see Section 8. The number space is limited,
and care should be taken not to fill the space.
22.3.2. Registering New Status Codes with IANA
A new status code registration follows the policy of IETF Review [RFC5226]. New RTSP functionality requiring Status Codes should first be registered in the range of x50-x99. Only when the range is full should registrations be made in the x00-x49 range, unless it is to adopt an HTTP extension to RTSP. This is done to enable any HTTP extension to be adopted to RTSP without needing to renumber any related status codes. A specification for a new status code must include the following: o The registered number. o A description of what the status code means and the expected behavior of the sender and receiver of the code.22.3.3. Registered Entries
RFC 7826 (this document) registers the numbered status code defined in the ABNF entry "Status-Code", except "extension-code" (that defines the syntax allowed for future extensions) in Section 20.2.2.22.4. RTSP Headers
22.4.1. Description
By specifying new headers, one or more methods can be enhanced in many different ways. An unknown header will be ignored by the receiving agent. If the new header is vital for certain functionality, a feature tag for the functionality can be created and demanded to be used by the counterpart with the inclusion of a Require header carrying the feature tag.22.4.2. Registering New Headers with IANA
Registrations can be made following the Expert Review policy [RFC5226]. A specification is recommended to be provided, preferably an RFC or other specification from a Standards Developing Organization. The minimal information in a registration request is the header name and the contact information. The expert reviewer verifies that the registration request contains the following information: o The name of the header. o An ABNF specification of the header syntax.
o A list or table specifying when the header may be used,
encompassing all methods, their request or response, and the
direction (C->S or S->C).
o How the header is to be handled by proxies.
o A description of the purpose of the header.
22.4.3. Registered Entries
All headers specified in Section 18 in RFC 7826 have been registered.
The registry includes the header name and reference.
Furthermore, the following legacy RTSP headers defined in other
specifications are registered with header name, and reference
according to below list. Note: these references may not fulfill all
of the above rules for registrations due to their legacy status.
o x-wap-profile defined in [TS-26234]. The x-wap-profile request-
header contains one or more absolute URLs to the requesting
agent's device-capability profile.
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff
request-header contains a subset of a device-capability profile.
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-
warning is a response-header that contains error codes explaining
to what extent the server has been able to match the terminal
request in regard to device-capability profiles, as described
using x-wap-profile and x-wap-profile-diff headers.
o x-predecbufsize defined in [TS-26234]. This response-header
provides an RTSP agent with the TS 26.234 Annex G hypothetical
pre-decoder buffer size.
o x-initpredecbufperiod defined in [TS-26234]. This response-header
provides an RTSP agent with the TS 26.234 Annex G hypothetical
pre-decoder buffering period.
o x-initpostdecbufperiod defined in [TS-26234]. This response-
header provides an RTSP agent with the TS 26.234 Annex G post-
decoder buffering period.
o 3gpp-videopostdecbufsize defined in [TS-26234]. This response-
header provides an RTSP agent with the TS 26.234 defined post-
decoder buffer size usable for H.264 (AVC) video streams.
o 3GPP-Link-Char defined in [TS-26234]. This request-header provides the RTSP server with the RTSP client's link characteristics as determined from the radio interface. The information that can be provided are guaranteed bitrate, maximum bitrate and maximum transfer delay. o 3GPP-Adaptation defined in [TS-26234]. This general-header is part of the bitrate adaptation solution specified for the Packet- switched Streaming Service (PSS). It provides the RTSP client's buffer sizes and target buffer levels to the server, and responses are used to acknowledge the support and values. o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is used by PSS RTSP agents to negotiate the quality of experience metrics that a client should gather and report to the server. o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is used by RTSP clients supporting PSS to report the actual values of the metrics gathered in its quality of experience metering. The use of "x-" is NOT RECOMMENDED, but the above headers in the list were defined prior to the clarification.22.5. Accept-Credentials
The security framework's TLS connection mechanism has two registerable entities.22.5.1. Accept-Credentials Policies
This registry is for policies for an RTSP proxy's handling and verification of TLS certificates when establishing an outbound TLS connection on behalf of a client. In Section 19.3.1, three policies for how to handle certificates are specified. Further policies may be defined; registration is made through Standards Action [RFC5226]. A registration request is required to contain the following information: o Name of the policy. o Text that describes how the policy works for handling the certificates. o A contact person.
This specification registers the following values:
Any: A policy requiring the proxy to accept any received
certificate.
Proxy: A policy where the proxy applies its own policies to
determine which certificates are accepted.
User: A policy where the certificate is required to be forwarded down
the proxy chain to the client, thus allowing the user to
decided to accept or refuse a certificate.
22.5.2. Accept-Credentials Hash Algorithms
The Accept-Credentials header (see Section 18.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely
rare and could also cause interoperability problems. Therefore, the
bar for registering new algorithms is intentionally placed high.
Any registration of a new hash algorithm requires Standards Action
[RFC5226]. The registration needs to fulfill the following
requirement:
o The algorithms identifier meeting the "token" ABNF requirement.
o Provide a definition of the algorithm.
The registered value is:
Hash Alg. ID Reference
------------------------
sha-256 RFC 7826
22.6. Cache-Control Cache Directive Extensions
There exist a number of cache directives that can be sent in the
Cache-Control header. A registry for these cache directives has been
established by IANA. New registrations in this registry require
Standards Action or IESG Approval [RFC5226]. A registration request
needs to contain the following information.
o The name of the cache directive.
o A definition of the parameter value, if any is allowed.
o The specification if it is a request or response directive.
o Text that explains how the cache directive is used for RTSP-
controlled media streams.
o A contact person.
This specification registers the following values:
no-cache:
public:
private:
no-transform:
only-if-cached:
max-stale:
min-fresh:
must-revalidate:
proxy-revalidate:
max-age:
The registry contains the name of the directive and the reference.
22.7. Media Properties
22.7.1. Description
The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases
that were in mind when writing the specification are defined.
However, it can be expected that further innovation will result in
new use cases or media streams with properties not covered by the
ones specified here. Thus, new media properties can be specified.
As new media properties may need a substantial amount of new
definitions to correctly specify behavior for this property, the bar
is intended to be high.
22.7.2. Registration Rules
Registering a new media property is done following the Specification Required policy [RFC5226]. The expert reviewer verifies that a registration request fulfills the following requirements. o An ABNF definition of the media property value name that meets "media-prop-ext" definition is included. o A definition of which media property group it belongs to or define a new group is included. o A description of all changes to the behavior of RTSP as result of these changes is included. o A contact person for the registration is listed.22.7.3. Registered Values
This specification registers the ten values listed in Section 18.29. The registry contains the property group, the name of the media property, and the reference.22.8. Notify-Reason Values
22.8.1. Description
Notify-Reason values are used to indicate the reason the notification was sent. Each reason has its associated rules on what headers and information may or must be included in the notification. New notification behaviors need to be specified to enable interoperable usage; thus, a specification of each new value is required.22.8.2. Registration Rules
Registrations for new Notify-Reason values follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements: o An ABNF definition of the Notify-Reason value name that meets "Notify-Reason-extension" definition is included. o A description of which headers shall be included in the request and response, when it should be sent, and any effect it has on the server client state is made clear. o A contact person for the registration is listed.
22.8.3. Registered Values
This specification registers three values defined in the Notify-Reas- val ABNF, Section 20.2.3: end-of-stream: This Notify-Reason value indicates the end of a media stream. media-properties-update: This Notify-Reason value allows the server to indicate that the properties of the media have changed during the playout. scale-change: This Notify-Reason value allows the server to notify the client about a change in the scale of the media. The registry contains the name, description, and reference.22.9. Range Header Formats
22.9.1. Description
The Range header (Section 18.40) allows for different range formats. These range formats also need an identifier to be used in the Accept- Ranges header (Section 18.5). New range formats may be registered, but moderation should be applied as it makes interoperability more difficult.22.9.2. Registration Rules
A registration follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements: o An ABNF definition of the range format that fulfills the "range- ext" definition is included. o The range format identifier used in Accept-Ranges header according to the "extension-format" definition is defined. o Rules for how one handles the range when using a negative Scale are included. o A contact person for the registration is listed.
22.9.3. Registered Values
The registry contains the Range header format identifier, the name of the range format, and the reference. This specification registers the following values. npt: Normal Play Time clock: UTC Absolute Time format smpte: SMPTE Timestamps smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop) smpte-25: SMPTE Timestamps 25 Frames/sec22.10. Terminate-Reason Header
The Terminate-Reason header (Section 18.52) has two registries for extensions.22.10.1. Redirect Reasons
This registry contains reasons for session termination that can be included in a Terminate-Reason header (Section 18.52). Registrations follow the Expert Review policy [RFC5226]. The expert reviewer verifies that the registration request contains the following information: o That the value follows the Terminate-Reason ABNF, i.e., be a token. o That the specification provide a definition of what procedures are to be followed when a client receives this redirect reason. o A contact person This specification registers three values: o Session-Timeout o Server-Admin o Internal-Error The registry contains the name of the Redirect Reason and the reference.
22.10.2. Terminate-Reason Header Parameters
This registry contains parameters that may be included in the Terminate-Reason header (Section 18.52) in addition to a reason. Registrations are made under the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request contains the following: o A parameter name. o A parameter following the syntax allowed by the RTSP 2.0 specification. o A reference to the specification. o A contact person. This specification registers: o time o user-msg The registry contains the name of the Terminate Reason and the reference.22.11. RTP-Info Header Parameters
22.11.1. Description
The RTP-Info header (Section 18.45) carries one or more parameter value pairs with information about a particular point in the RTP stream. RTP extensions or new usages may need new types of information. As RTP information that could be needed is likely to be generic enough, and to maximize the interoperability, new registration is made under the Specification Required policy.22.11.2. Registration Rules
Registrations for new RTP-Info values follow the policy of Specification Required [RFC5226]. The expert reviewer verifies that the registration request contains the following information. o An ABNF definition that meets the "generic-param" definition. o A reference to the specification. o A contact person for the registration.
22.11.3. Registered Values
This specification registers the following parameter value pairs: o url o ssrc o seq o rtptime The registry contains the name of the parameter and the reference.22.12. Seek-Style Policies
22.12.1. Description
Seek-Style policy defines how the RTSP agent seeks in media content when given a position within the media content. New seek policies may be registered; however, a large number of these will complicate implementation substantially. The impact of unknown policies is that the server will not honor the unknown and will use the server default policy instead.22.12.2. Registration Rules
Registrations of new Seek-Style policies follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements: o Has an ABNF definition of the Seek-Style policy name that meets "Seek-S-value-ext" definition. o Includes a short description. o Lists a contact person for the registration. o Includes a description of which headers shall be included in the request and response, when it should be sent, and any affect it has on the server-client state.22.12.3. Registered Values
This specification registers four values (Name - Short Description): o RAP - Using the closest Random Access Point prior to or at the requested start position.
o CoRAP - Conditional Random Access Point is like RAP, but only if
the RAP is closer prior to the requested start position than
current pause point.
o First-Prior - The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested
start position.
o Next - The next media units after the provided start position.
The registry contains the name of the Seek-Style policy, the
description, and the reference.
22.13. Transport Header Registries
The transport header (Section 18.54) contains a number of parameters
that have possibilities for future extensions. Therefore, registries
for these are defined below.
22.13.1. Transport Protocol Identifier
A Transport Protocol specification consists of a transport protocol
identifier, representing some combination of transport protocols, and
any number of transport header parameters required or optional to use
with the identified protocol specification. This registry contains
the identifiers used by registered transport protocol identifiers.
A registration for the parameter transport protocol identifier
follows the Specification Required policy [RFC5226]. The expert
reviewer verifies that the registration request fulfills the
following requirements:
o A contact person or organization with address and email.
o A value definition that follows the ABNF syntax definition of
"transport-id" Section 20.2.3.
o A descriptive text that explains how the registered values are
used in RTSP, which underlying transport protocols are used, and
any required Transport header parameters.
The registry contains the protocol ID string and the reference.
This specification registers the following values: RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] over UDP. The usage is explained in RFC 7826, Appendix C.1. RTP/AVP/UDP: the same as RTP/AVP. RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is explained in RFC 7826, Appendix C.1. RTP/AVPF/UDP: the same as RTP/AVPF. RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 7826, Appendix C.1. RTP/SAVP/UDP: the same as RTP/SAVP. RTP/SAVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] over UDP. The usage is explained in RFC 7826, Appendix C.1. RTP/SAVPF/UDP: the same as RTP/SAVPF. RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over TCP. The usage is explained in RFC 7826, Appendix C.2.2. RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is explained in RFC 7826, Appendix C.2.2. RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real- time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.22.13.2. Transport Modes
The Transport Mode is a Transport header (Section 18.54) parameter. It is used to identify the general mode of media transport. The PLAY value registered defines a PLAYBACK mode, where media flows from server to client. A registration for the transport parameter mode follows the Standards Action policy [RFC5226]. The registration request needs to meet the following requirements: o A value definition that follows the ABNF "token" definition Section 20.2.3. o Text that explains how the registered value is used in RTSP. This specification registers one value: PLAY: See RFC 7826. The registry contains the transport mode value and the reference.22.13.3. Transport Parameters
Transport Parameters are different parameters used in a Transport header's transport specification (Section 18.54) to provide additional information required beyond the transport protocol identifier to establish a functioning transport. A registration for parameters that may be included in the Transport header follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements: o A Transport Parameter Name following the "token" ABNF definition. o A value definition, if the parameter takes a value, that follows the ABNF definition of "trn-par-value" Section 20.2.3. o Text that explains how the registered value is used in RTSP.
This specification registers all the transport parameters defined in Section 18.54. This is a copy of that list: o unicast o multicast o interleaved o ttl o layers o ssrc o mode o dest_addr o src_addr o setup o connection o RTCP-mux o MIKEY The registry contains the transport parameter name and the reference.22.14. URI Schemes
This specification updates two URI schemes: one previously registered, "rtsp", and one missing in the registry, "rtspu" (previously only defined in RTSP 1.0 [RFC2326]). One new URI scheme, "rtsps", is also registered. These URI schemes are registered in an existing registry ("Uniform Resource Identifier (URI) Schemes") not created by this memo. Registrations follow [RFC7595].22.14.1. The "rtsp" URI Scheme
URI scheme name: rtsp Status: Permanent URI scheme syntax: See Section 20.2.1 of RFC 7826.
URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-Time Streaming
Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However, the
operations that are currently defined are DESCRIBE,
GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
SETUP, SET_PARAMETER, and TEARDOWN.
Encoding considerations: IRIs in this scheme are defined and need to
be encoded as RTSP URIs when used within RTSP. That encoding
is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC 7826).
Interoperability considerations: The extensions in the URI syntax
performed between RTSP 1.0 and 2.0 can create interoperability
issues. The changes are:
Support for IPv6 literals in the host part and future IP
literals through a mechanism as defined in RFC 3986.
A new relative format to use in RTSP elements that is not
required to start with "/".
The above changes should have no impact on interoperability as
discussed in detail in Section 4.2 of RFC 7826.
Security considerations: All the security threats identified in
Section 7 of RFC 3986 also apply to this scheme. They need to
be reviewed and considered in any implementation utilizing this
scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
22.14.2. The "rtsps" URI Scheme
URI scheme name: rtsps
Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC 7826.
URI scheme semantics: The rtsps scheme is used to indicate resources
accessible through the usage of the Real-Time Streaming
Protocol (RTSP) over TLS. RTSP allows different operations on
the resource identified by the URI, but the primary purpose is
the streaming delivery of the resource to a client. However,
the operations that are currently defined are DESCRIBE,
GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
SETUP, SET_PARAMETER, and TEARDOWN.
Encoding considerations: IRIs in this scheme are defined and need to
be encoded as RTSP URIs when used within RTSP. That encoding
is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC 7826).
Interoperability considerations: The "rtsps" scheme was never
officially defined for RTSP 1.0; however, it has seen
widespread use in actual deployments of RTSP 1.0. Therefore,
this section discusses the believed changes between the
unspecified RTSP 1.0 "rtsps" scheme and RTSP 2.0 definition.
The extensions in the URI syntax performed between RTSP 1.0 and
2.0 can create interoperability issues. The changes are:
Support for IPv6 literals in the host part and future IP
literals through a mechanism as defined by RFC 3986.
A new relative format to use in RTSP elements that is not
required to start with "/".
The above changes should have no impact on interoperability as
discussed in detail in Section 4.2 of RFC 7826.
Security considerations: All the security threats identified in
Section 7 of RFC 3986 also apply to this scheme. They need to
be reviewed and considered in any implementation utilizing this
scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
22.14.3. The "rtspu" URI Scheme
URI scheme name: rtspu Status: Permanent URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme semantics: The rtspu scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP) over unreliable datagram transport. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN. Encoding considerations: This scheme is not intended to be used with characters outside the US-ASCII repertoire. Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326). Interoperability considerations: The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic. Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme. Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Author/Change controller: IETF References: RFC 2326
22.15. SDP Attributes
This specification defines three SDP [RFC4566] attributes that have been registered by IANA. SDP Attribute ("att-field"): Attribute name: range Long form: Media Range Attribute Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: See ABNF definition. Attribute name: control Long form: RTSP control URI Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: Absolute or Relative URIs. Attribute name: mtag Long form: Message Tag Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 7826 Values: See ABNF definition22.16. Media Type Registration for text/parameters
Type name: text Subtype name: parameters Required parameters: Optional parameters: charset: The charset parameter is applicable to the encoding of the parameter values. The default charset is UTF-8, if the 'charset' parameter is not present. Encoding considerations: 8bit
Security considerations: This format may carry any type of
parameters. Some can have security requirements, like privacy,
confidentiality, or integrity requirements. The format has no
built-in security protection. For the usage, the transport can be
protected between server and client using TLS. However, care must
be taken to consider if the proxies are also trusted with the
parameters in case hop-by-hop security is used. If stored as a
file in a file system, the necessary precautions need to be taken
in relation to the parameter requirements including object
security such as S/MIME [RFC5751].
Interoperability considerations: This media type was mentioned as a
fictional example in [RFC2326], but was not formally specified.
This has resulted in usage of this media type that may not match
its formal definition.
Published specification: RFC 7826, Appendix F.
Applications that use this media type: Applications that use RTSP
and have additional parameters they like to read and set using the
RTSP GET_PARAMETER and SET_PARAMETER methods.
Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Magnus Westerlund (magnus.westerlund@ericsson.com)
Intended usage: Common
Restrictions on usage: None
Author: Magnus Westerlund (magnus.westerlund@ericsson.com)
Change controller: IETF
Addition Notes:
(next page on part 11)
