Adobe’s Real-Time Messaging Protocol (RTMP) comprises a family of network protocols for transporting streams of time-oriented video, audio, and data messages over IP networks. The URI schemes that are used to identify, locate, and access streaming resources in the RTMP family follow the URI Generic Syntax of RFC 3986, with constraints. This memo describes the syntax constraints and the access semantics for RTMP family URIs.
Copyright © 2023 Michael Thornburgh. All rights reserved.
SPDX-License-Identifier: MIT
RTMP and its TCP-based transport (the RTMP Chunk Stream) are described in the RTMP Specification of December 2012. Errors, omissions, and ambiguities in that specification are addressed in RTMP Errata and Addenda. Coordinated interoperable enhancements to RTMP are described in Enhancing RTMP, FLV With Additional Video Codecs and HDR Support. Transporting RTMP messages over the Secure Real-Time Media Flow Protocol (RTMFP) [RFC7016] is described in Adobe’s RTMFP Profile for Flash Communication [RFC7425].
This memo does not address private or undocumented extensions to the RTMP family for which interoperation is not desired by the extending parties.
The primary operation for dereferencing an RTMP family URI is to connect to the indicated origin server and its abstract target resource. Neither the connection itself nor the target resource have a “representation” or a “media type” in the senses described in RFC 3986, nor is a “retrieval” performed by connecting.
The target resource can have secondary resources, such as streams, shared objects, and remote procedures, that can be accessed according their kinds via the connection. For example, streams may be published or played, shared objects updated or observed, and remote procedures called.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The terms “client”, “server”, “origin server”, “resource”, “secondary resource”, “dereference”, “representation”, and “media type” in this document are to be interpreted as used or described in RFC 3986.
RTMP family URIs follow the Generic Syntax of RFC 3986, with constraints.
Their syntax is described here using the
Augmented Backus-Naur Form (ABNF) [RFC5234] rules from RFC 3986,
which are incorporated by reference as though fully set forth here. The host
rule is also reproduced here for clarity in the following sections. Note
that the rtmp-authority
rule defined here is compatible with the authority
rule, and rtmp-userinfo
is compatible with the userinfo
rule.
rtmp-URI = "rtmp://" rtmp-authority path-abempty [ "?" query ] [ "#" fragment ]
rtmps-URI = "rtmps://" rtmp-authority path-abempty [ "?" query ] [ "#" fragment ]
rtmfp-URI = "rtmfp:"
/ "rtmfp://" rtmp-authority path-abempty [ "?" query ] [ "#" fragment ]
rtmp-authority = [ rtmp-userinfo "@" ] host [ ":" port ]
rtmp-userinfo = rtmp-connect-arg *( ":" rtmp-connect-arg )
rtmp-connect-arg = *( unreserved / pct-encoded / sub-delims )
host = IP-literal / IPv4address / reg-name
The rtmp-authority
component, when present, identifies the location of an RTMP
origin server which governs a namespace of target and secondary resources.
Note: The bare RTMFP URI form “rtmfp:
” does not have an rtmp-authority
component (or any other components). All of the other URI forms do. The bare
“rtmfp:
” URI is used in the APIs of some implementations to indicate
instantiation of an RTMFP client according to RFC 7425, but without
connecting to a server. Such an instantiation might be used for pure
peer-to-peer communication.
The host
and optional port
components identify the origin server in the
network. The host
component of the rtmp-authority
MUST NOT be empty.
For an rtmp-URI
, the host
and optional port
identify a potential origin
server listening for TCP connections, over which RTMP messages are to be sent
using the RTMP Chunk Stream as described in the RTMP Specification.
If the port
is empty or not given, TCP port 1935 is the default.
For an rtmps-URI
, the host
and optional port
identify a potential origin
server listening for TCP connections and capable of establishing a TLS
connection secured for RTMP Chunk Stream communication. “Secured”
means a connection that is authenticated, confidential, and integrity-protected
in a manner acceptable to both the client and server. If the port
is empty
or not given, TCP port 443 is the default.
For an rtmfp-URI
where the rtmp-authority
is present, the host
and optional
port
identify one or more initial candidate addresses with which to initiate
an RTMFP connection according to RFC 7425. The UDP port for
the initial candidate addresses, if empty or not specified, is 1935. If
host
is a reg-name
, the initial candidate address set SHOULD comprise
all IPv4 and IPv6 addresses to which reg-name
resolves.
When connecting to an RTMP server, the
connect
command can
accept or expect additional arguments following the Command Object. The number
and types of the additional arguments, their interpretation, and whether they
are expected is implementation-specific and is the prerogative of the server.
Often the server expects one or more string arguments to the connect
command
following the Command Object, for example a developer key, a user name and
password, or implementation-specific connection properties.
If the rtmp-authority
contains an rtmp-userinfo
component, and in the
absence of other arrangements between the client and server, the rtmp-userinfo
SHOULD be interpreted as a “:
” (COLON
) separated sequence of potentially
empty rtmp-connect-arg
strings (as illustrated in the ABNF) to be sent as
string arguments to the connect
command following the Command Object. Each
rtmp-connect-arg
SHOULD be percent-decoded before being sent.
Clients SHOULD remove the rtmp-userinfo
component from the URI when
sending it as the tcUrl
property of the connect
command’s Command Object
or in the
Ancillary Data option of an RTMFP Endpoint Discriminator.
The path-abempty
and query
components identify the abstract
target resource within the origin server’s namespace. The meaning of “target
resource” is implementation-specific and is the prerogative of the origin
server.
Interoperability Note: Some client implementations incorrectly presume
the server’s interpretation of the path-abempty
component of the URI,
specifically by presuming the number of path segments that identify the target
resource. These clients then incorrectly interpret the remaining path segments of the
original URI as identifying a secondary resource (such the name of a stream
to play or publish via the connection to the target resource). This behavior
is not in keeping with the spirit of generic URIs (particularly that the
authority
governs its namespace), is not interoperable, and is
NOT RECOMMENDED. Such secondary resources, when encoded in a URI, should
instead be identified by the fragment identifier as described in the next
section.
Section 3.5 of RFC 3986
describes the fragment
component of a generic URI as allowing “indirect
identification of a secondary resource by reference to a primary resource and
additional identifying information”.
Since an RTMP connection to a target resource has neither a “representation”
nor a “media type”, the semantics of the fragment
component are unconstrained
according to that section.
Often an RTMP client connects to a server to perform a specific operation on
a specific secondary resource, such as to publish to or play from a named
stream. In cases where the kind of secondary resource and the intended operation
are unambiguous, and in the absence of other arrangements between the client
and server, the secondary resource MAY be identified by the fragment
component. The fragment
SHOULD be percent-decoded before being used in
secondary resource APIs (for example in a stream play
command).
Clients SHOULD remove the fragment
component from the URI when sending
it as the tcUrl
property of the connect
command’s Command Object or in the
Ancillary Data option of an RTMFP Endpoint Discriminator.
rtmp://server.example/three/segment/path
rtmp://server.example/three/segment/path#BigBuckBunny
rtmp://[2001:db8:1::2]:19350/something?else
rtmps://server.example/something?else#CosmosLaundromat?aFlag
rtmps://arg1:arg2::arg4@server.example:1943
rtmps://name=Mike;pri=5;exi=3600:7c412a7b6e5892f9c@server.example/path#Caves
rtmfp://:arg2@redirectors.example/two/segments?key=value&flag
rtmfp://arg%3Aone:arg2@redirectors.example/something#BigBuck%42unny
rtmfp:
A future version of this memo will request the IANA to update the URI Scheme Registry for the following schemes.
rtmp
This section will request an update to the rtmp
provisional scheme registration.
URI scheme name: rtmp
Status: provisional
URI scheme syntax:
rtmp-URI = "rtmp://" authority path-abempty [ "?" query ] [ "#" fragment ]
URI scheme semantics: This provides location information for the RTMP
server to which to connect, and identifies a target resource and
an optional secondary resource in the namespace of the server. The
host component of the authority MUST NOT be empty. The host and
port components of the authority identify a potential origin server
listening for TCP connections, over which RTMP messages are to be
sent using the RTMP Chunk Stream as described in the RTMP Specification
(as amended). If port is empty or not given, TCP port 1935 is the
default.
See the RTMP Family URI Schemes memo for more specific information
regarding the semantics of this URI scheme.
Encoding considerations: The userinfo, path-abempty, query, and fragment
components represent textual data consisting of characters from
the Universal Character Set. These components SHOULD be encoded
according to Section 2.5 of RFC 3986.
Applications/protocols that use this URI scheme name: The Flash
runtime (including Flash Player) from Adobe, communication servers
such as Adobe Media Server, and interoperable clients and servers
provided by other parties.
Interoperability considerations: This scheme requires use of RTMP
and the RTMP Chunk Stream as defined by the RTMP Specification (as
amended).
Security considerations: See Security Considerations sections in
RTMP Errata and Addenda and in RTMP Family URI Schemes.
Contact: Michael Thornburgh, <zenomt@zenomt.com>.
Author/Change controller: Michael Thornburgh, <zenomt@zenomt.com>.
References:
Parmar, H., Ed. and M. Thornburgh, Ed., "Adobe’s Real Time Messaging
Protocol" ("RTMP Specification"), December 2012,
<https://rtmp.veriskope.com/docs/spec/>.
Thornburgh, M., "RTMP Errata and Addenda", September 2023,
<https://zenomt.github.io/rtmp-errata-addenda/>.
Thornburgh, M., "RTMP Family URI Schemes", September 2023,
<TBD>.
rtmps
This section will request provisional registration of the rtmps
scheme.
URI scheme name: rtmps
Status: provisional
URI scheme syntax:
rtmps-URI = "rtmps://" authority path-abempty [ "?" query ] [ "#" fragment ]
URI scheme semantics: This provides location information for the secure
RTMP server to which to connect, and identifies a target resource
and an optional secondary resource in the namespace of the server.
The host component of the authority MUST NOT be empty. The host
and optional port components of the authority identify a potential
origin server listening for TCP connections and capable of establishing
a TLS connection secured for RTMP Chunk Stream communication, over
which RTMP messages are to be sent using RTMP Chunk Stream as
described in the RTMP Specification (as amended). If port is empty
or not given, TCP port 443 is the default.
See the RTMP Family URI Schemes memo for more specific information
regarding the semantics of this URI scheme.
Encoding considerations: The userinfo, path-abempty, query, and fragment
components represent textual data consisting of characters from
the Universal Character Set. These components SHOULD be encoded
according to Section 2.5 of RFC 3986.
Applications/protocols that use this URI scheme name: The Flash
runtime (including Flash Player) from Adobe, communication servers
such as Adobe Media Server, and interoperable clients and servers
provided by other parties.
Interoperability considerations: This scheme requires use of RTMP
and the RTMP Chunk Stream as defined by the RTMP Specification (as
amended).
Security considerations: See Security Considerations sections in
RTMP Errata and Addenda and in RTMP Family URI Schemes.
Contact: Michael Thornburgh, <zenomt@zenomt.com>.
Author/Change controller: Michael Thornburgh, <zenomt@zenomt.com>.
References:
Parmar, H., Ed. and M. Thornburgh, Ed., "Adobe’s Real Time Messaging
Protocol" ("RTMP Specification"), December 2012,
<https://rtmp.veriskope.com/docs/spec/>.
Thornburgh, M., "RTMP Errata and Addenda", September 2023,
<https://zenomt.github.io/rtmp-errata-addenda/>.
Thornburgh, M., "RTMP Family URI Schemes", September 2023,
<TBD>.
rtmfp
This section will request an update to the rtmfp
provisional scheme registration.
URI scheme name: rtmfp
Status: provisional
URI scheme syntax:
rtmfp-URI = "rtmfp:"
/ "rtmfp://" authority path-abempty [ "?" query ] [ "#" fragment ]
URI scheme semantics: The first form is used in the APIs of some
implementations to indicate instantiation of an RTMFP client
according to RFC 7425, but without connecting to a server. Such
an instantiation might be used for pure peer-to-peer communication.
The second form provides location information for the server to
which to connect, and identifies a target resource and an optional
secondary resource in the namespace of the server. Connections are
made using RTMFP (RFC 7016) as described by RFC 7425. The host
component of the authority MUST NOT be empty. If host is a reg-name,
the initial candidate address set SHOULD comprise all IPv4 and IPv6
addresses to which reg-name resolves. The UDP port for the initial
candidate addresses for the server, if not specified, is 1935.
See the RTMP Family URI Schemes memo for more specific information
regarding the semantics of this URI scheme.
Encoding considerations: The userinfo, path-abempty, query, and fragment
components represent textual data consisting of characters from
the Universal Character Set. These components SHOULD be encoded
according to Section 2.5 of RFC 3986.
Applications/protocols that use this URI scheme name: The Flash
runtime (including Flash Player) from Adobe, communication servers
such as Adobe Media Server, and interoperable clients and servers
provided by other parties, using RTMFP according to RFC 7425.
Interoperability considerations: This scheme requires use of RTMFP
as defined by RFC 7016 in the manner described by RFC 7425.
Security considerations: See Security Considerations (Section 7) in
RFC 7425, and Section 9 of RTMP Errata and Addenda.
Contact: Michael Thornburgh, <zenomt@zenomt.com>.
Author/Change controller: Michael Thornburgh, <zenomt@zenomt.com>.
References:
Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
RFC 7016, November 2013.
Thornburgh, M., "Adobe's RTMFP Profile for Flash Communication",
RFC 7425, December 2014.
Thornburgh, M., "RTMP Errata and Addenda", September 2023,
<https://zenomt.github.io/rtmp-errata-addenda/>.
Thornburgh, M., "RTMP Family URI Schemes", September 2023,
<TBD>.
Several. See the Security Considerations sections of RFC 7016, RFC 7425, and RTMP Errata and Addenda.
Many of the security considerations of RFC 9110 also apply to RTMP.
Michael C. Thornburgh
Santa Cruz, CA 95060-1950
United States of America
Email: zenomt@zenomt.com
URI: https://zenomt.zenomt.com/card.ttl#me