| RTMP URIs | July 2024 | |
| Thornburgh | Informational | [Page] |
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.¶
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:¶
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.¶
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.¶
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 [RFC3986], with constraints.¶
RTMP and its TCP-based transport (the RTMP Chunk Stream) are described in the RTMP Specification of December 2012 [RTMP]. Errors, omissions, and ambiguities in that specification are addressed in RTMP Errata and Addenda [RTMP-Errata]. Coordinated interoperable enhancements to RTMP are described in Enhanced RTMP [E-RTMP]. 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 describes the syntax constraints and the access semantics for RTMP family URIs.¶
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 [RFC3986].¶
RTMP family URIs follow the Generic Syntax of [RFC3986],
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://" common
rtmps-URI = "rtmps://" common
rtmfp-URI = "rtmfp:" ["//" common]
common = 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
[RFC7425], but without connecting to a server. Such an
instantiation might be used for pure peer-to-peer communication.¶
The host and optional port components locate 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 [RFC0793]
connections, over which RTMP messages are to be sent using the RTMP Chunk
Stream as described in the RTMP Specification [RTMP]. 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 [RFC8446] connection secured for
RTMP Chunk Stream communication [RTMP]. "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 [RFC7016]
connection according to [RFC7425]. The
UDP [RFC0768] 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
(Section 7.2.1.1 of [RTMP]) 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
(Section 4.4.2.2 of [RFC7425]).¶
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 as 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 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 [RFC3986] 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
(Section 4.4.2.2 of [RFC7425]).¶
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:7c412a7b6e@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 of the IANA to update the URI Scheme Registry [SCHEMES] for the following schemes.¶
This section will request an update to the rtmp provisional scheme
registration.¶
rtmp¶
rtmp-URI = "rtmp://" common
common = 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)
¶
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 optional 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.¶
rtmp-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.¶
<zenomt@zenomt.com>.¶
<zenomt@zenomt.com>.¶
<https://veovera.org/docs/legacy/rtmp-v1-0-spec.pdf>.¶
<https://zenomt.github.io/rtmp-errata-addenda/>.¶
<https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.¶
<https://veovera.org/>.¶
This section will request provisional registration of the rtmps scheme.¶
rtmps¶
rtmps-URI = "rtmps://" common
common = 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)
¶
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 the 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.¶
rtmp-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.¶
<zenomt@zenomt.com>.¶
<zenomt@zenomt.com>.¶
<https://veovera.org/docs/legacy/rtmp-v1-0-spec.pdf>.¶
<https://zenomt.github.io/rtmp-errata-addenda/>.¶
<https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.¶
<https://veovera.org/>.¶
This section will request an update to the rtmfp provisional scheme registration.¶
rtmfp¶
rtmfp-URI = "rtmfp:" ["//" common]
common = 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)
¶
The scheme-only 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 full form provides location information for the RTMFP
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.¶
rtmp-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.¶
<zenomt@zenomt.com>.¶
<zenomt@zenomt.com>.¶
<https://zenomt.github.io/rtmp-errata-addenda/>.¶
<https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.¶
Several. See the Security Considerations sections of [RFC7016], [RFC7425], and [RTMP-Errata].¶
Many of the security considerations of [RFC9110] also apply to RTMP.¶