Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7826

 
 
 

Real-Time Streaming Protocol Version 2.0

Part 10 of 13, p. 213 to 239
Prev Section       Next Section

 


prevText      Top      ToC       Page 213 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 Section