Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7826

Real-Time Streaming Protocol Version 2.0

Pages: 318
Proposed Standard
Obsoletes:  2326
Part 10 of 13 – Pages 213 to 239
First   Prev   Next

Top   ToC   RFC7826 - Page 213   prevText

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.
Top   ToC   RFC7826 - Page 214
   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.
Top   ToC   RFC7826 - Page 215

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.
Top   ToC   RFC7826 - Page 216
   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
Top   ToC   RFC7826 - Page 217
   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
Top   ToC   RFC7826 - Page 218
   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
Top   ToC   RFC7826 - Page 219
   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.
Top   ToC   RFC7826 - Page 220
   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.
Top   ToC   RFC7826 - Page 221

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.
Top   ToC   RFC7826 - Page 222
   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.
Top   ToC   RFC7826 - Page 223
   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.
Top   ToC   RFC7826 - Page 224
   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.
Top   ToC   RFC7826 - Page 225
   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.
Top   ToC   RFC7826 - Page 226

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.
Top   ToC   RFC7826 - Page 227

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.
Top   ToC   RFC7826 - Page 228

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/sec

22.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.
Top   ToC   RFC7826 - Page 229

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.
Top   ToC   RFC7826 - Page 230

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.
Top   ToC   RFC7826 - Page 231
   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.
Top   ToC   RFC7826 - Page 232
   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.
Top   ToC   RFC7826 - Page 233
   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.
Top   ToC   RFC7826 - Page 234
   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.
Top   ToC   RFC7826 - Page 235
   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.
Top   ToC   RFC7826 - Page 236
   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
Top   ToC   RFC7826 - Page 237

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
Top   ToC   RFC7826 - Page 238

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 definition

22.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
Top   ToC   RFC7826 - Page 239
   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)

Next Section