RTMP URIs July 2024
Thornburgh Informational [Page]
Published:
Author:
M. Thornburgh

RTMP Family URI Schemes

Abstract

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.

Table of Contents

1. Introduction

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.

2. Terminology

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].

3. Syntax

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

4. Authority

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.

4.1. Host and Port

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.

4.2. Userinfo

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]).

5. Path and Query

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.

6. Fragment Identifier

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]).

7. Examples

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:

8. IANA Considerations

A future version of this memo will request of the IANA to update the URI Scheme Registry [SCHEMES] for the following schemes.

8.1. RTMP Registration

This section will request an update to the rtmp provisional scheme registration.

Scheme Name:
rtmp
Status:
provisional
URI scheme syntax:
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)
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 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.

Encoding considerations:
The 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.
Applications/protocols that use this URI scheme name:
Computer program products that use Adobe's Real-Time Messaging Protocol (RTMP) to transport streams of time-oriented video, audio, and data messages over IP networks.
Interoperability considerations:
This scheme requires use of RTMP and the RTMP Chunk Stream as defined by the RTMP Specification (as amended).
Security considerations:
See the 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://veovera.org/docs/legacy/rtmp-v1-0-spec.pdf>.
  • Thornburgh, M., "RTMP Errata and Addenda", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/>.
  • Thornburgh, M., "RTMP Family URI Schemes", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.
  • Lozben, S., "Enhanced RTMP", June 2024, <https://veovera.org/>.

8.2. RTMPS Registration

This section will request provisional registration of the rtmps scheme.

Scheme Name:
rtmps
Status:
provisional
URI scheme syntax:
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)
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 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.

Encoding considerations:
The 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.
Applications/protocols that use this URI scheme name:
Computer program products that use Adobe's Real-Time Messaging Protocol (RTMP) to securely transport streams of time-oriented video, audio, and data messages over IP networks.
Interoperability considerations:
This scheme requires use of RTMP and the RTMP Chunk Stream as defined by the RTMP Specification (as amended) over TLS.
Security considerations:
See the 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://veovera.org/docs/legacy/rtmp-v1-0-spec.pdf>.
  • Thornburgh, M., "RTMP Errata and Addenda", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/>.
  • Thornburgh, M., "RTMP Family URI Schemes", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.
  • Lozben, S., "Enhanced RTMP", June 2024, <https://veovera.org/>.

8.3. RTMFP Registration

This section will request an update to the rtmfp provisional scheme registration.

Scheme Name:
rtmfp
Status:
provisional
URI scheme syntax:
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)
URI scheme semantics:

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.

Encoding considerations:
The 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.
Applications/protocols that use this URI scheme name:
Computer program products that use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) according to RFC 7425 to transport streams of time-oriented video, audio, and data messages over IP networks.
Interoperability considerations:
This scheme requires use of RTMFP as defined by RFC 7016 in the manner described by RFC 7425.
Security considerations:
See the Security Considerations sections of RFC 7016, RFC 7425, and 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", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/>.
  • Thornburgh, M., "RTMP Family URI Schemes", July 2024, <https://zenomt.github.io/rtmp-errata-addenda/rtmp-uris/>.

9. Security Considerations

Several. See the Security Considerations sections of [RFC7016], [RFC7425], and [RTMP-Errata].

Many of the security considerations of [RFC9110] also apply to RTMP.

10. References

10.1. Normative References

[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC0793]
Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, , <https://www.rfc-editor.org/info/rfc793>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC7016]
Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, DOI 10.17487/RFC7016, , <https://www.rfc-editor.org/info/rfc7016>.
[RFC7425]
Thornburgh, M., "Adobe's RTMFP Profile for Flash Communication", RFC 7425, DOI 10.17487/RFC7425, , <https://www.rfc-editor.org/info/rfc7425>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
[RTMP]
Parmar, H., Ed. and M. Thornburgh, Ed., "Adobe’s Real Time Messaging Protocol", , <https://veovera.org/docs/legacy/rtmp-v1-0-spec.pdf>.

10.2. Informative References

[E-RTMP]
Lozben, S., "Enhanced RTMP", , <https://veovera.org/>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[RTMP-Errata]
Thornburgh, M., "RTMP Errata and Addenda", , <https://zenomt.github.io/rtmp-errata-addenda/>.
[SCHEMES]
Internet Assigned Numbers Authority, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes/>.

Author's Address

Michael C. Thornburgh
Santa Cruz, CA 95060-1950
United States of America