Internet-Draft The WebRTC URI Scheme October 2022
Jiang,Jianxing Expires 5 April 2023 [Page]
Network Working Group
Intended Status:
Standards Track

The WebRTC URI Scheme


This document registers the "wr://" and "wrs://" URI schemes to aid in the connect of WebRTC.

Note to Readers

RFC EDITOR: please remove this section before publication

The issues list for this draft can be found at

The most recent (unpublished) draft and demos is at

Recent changes are listed at

See also the draft's current status in the IETF datatracker, at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 April 2023.

Table of Contents

1. Introduction

URI is short and compact, convenient for transmission. You can even send it offline to others without using any server, for example, you can generate a QR Code for use.

WebRTC is a widely used real-time connection protocol, but unlike WebSocket, it has no URI scheme.

This document registers the "wr://" and "wrs://" URI schemes to aid prevention of such accidental disclosures. When use the URI quickly open the connection, you can immediately to realize communication between two clients.

Use this URI Scheme to easily open a connection. You can open a data channel, then the connection can be used as a file transfer or signalling server, etc. You can also directly open a stable and complex connection by passing more parameters.

WebRTC URI Scheme defines one endpoint of the connection, rather than one port of the device. It defines the connection mode of WebRTC in the Internet/LAN that conforms to human intuition. One device can open multiple connections, corresponding to multiple endpoints, without paying special attention to which port is currently used for connection.

WebRTC URI Scheme may look like a compressed version of the SDP file. It avoids the trouble of inconvenient transmission of SDP newline characters, and does not expose more information in the first connection.

In addition, the WebRTC URI Scheme facilitates communication between two computers through browser application under the premise of light server or no server. Changing connections on the network connect pairs of endpoints. WebRTC endpoints are characterized by great variability and fast variability. We can dynamically connect these points to form a dynamic network.

1.1. Notational Conventions

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.

This document uses ABNF [RFC5234], Base64 [RFC4648]. It also uses the pchar rule from [RFC3986].

2. WebRTC URIs

This specification defines two URI schemes, using the ABNF syntax defined in RFC 5234 [RFC5234], and terminology and ABNF productions defined by the URI specification RFC 3986 [RFC3986].

       wr-URI = "wr" ":" [ host-part ] "/" endpoint [ "?" query ]
       wrs-URI = "wrs" ":" [ host-part ] "/" endpoint [ "?" query ]
       host-part = "//" [ hostport ]

       hostport = host [ ":" port ]
       host = <host, defined in [RFC3986], Section 3.2.2>
       port = <port, defined in [RFC3986], Section 3.2.3>
       endpoint = basehash ufrag pwd
       query = <query, defined in [RFC3986], Section 3.4>

       basehash = 44<pchar>
       ufrag = *255<pchar>
       pwd = *255<pchar>

See [RFC3986], Section 3.3 for a definition of pchar. Disallowed characters -- including non-ASCII characters -- MUST be encoded into UTF-8 [RFC3629] and then percent-encoded ([RFC3986], Section 2.1).

The hostport component is OPTIONAL; By default, WebRTC connection without STUN or TURN.

The port component is OPTIONAL; By default, "wr" runs on the same ports as STUN and TURN: 3478 for "wr" over UDP and TCP, and 5349 for "wrs" over TLS.

The ufrag component, pwd component and fingerprint used in basehash component below can be find in attributes ([RFC8859], Section 5.12) of SDP ([RFC8864], Section 5.12).

The basehash component MUST be calculated by the following steps:

  1. get the length of ufrag component
  2. convert length of ufrag component to hexadecimal (1 Byte)
  3. get the fingerprint hexadecimal (32 Byte)
  4. connect the length hexadecimal after the fingerprint hexadecimal
  5. Calculate the Base64([RFC3986], Section 2.1) of the result
    (33 Byte)

The advantage of this is to take endpoint component as a whole while taking readability into consideration.

Fragment identifiers are meaningless in the context of WebRTC URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23.

Example URIs are listed in Appendix A.

3. IANA Considerations

3.1. Registration of New URI Schemes

3.1.1. Registration of "wr" Scheme

A |wr| URI identifies a WebRTC offer and answer name.

Scheme name:




Applications/protocols that use this scheme:

none yet

Security considerations:

See "Security Considerations" section.



Change controller:



(this document)

3.1.2. Registration of "wrs" Scheme

A |wrs| URI identifies a WebRTC offer and answer name and indicates that traffic over that connection is to be protected via TLS (including standard benefits of TLS such as data confidentiality and integrity and endpoint authentication).

Scheme name:




Applications/protocols that use this scheme:

none yet

Security considerations:

See "Security Considerations" section.



Change controller:



(this document)

4. Security Considerations

The token ABNF rule allows tokens as small as 0 character. This is not recommended practice; applications should evaluate their requirements for entropy and issue tokens correspondingly. See [RFC8445] for more information.

This document not solve the problem that attackers can flood stun/turn servers. Too many open ports may cause network layer rejection.

Although the WebRTC URI Scheme makes connections easy to open, you may connect untrusted nodes in static pages, just like click the link of a phishing website. Before connecting, you must confirm whether the URI provider is trusted.

If the stun/turn server is not trusted, man-in-the-middle attack may occur on the "ws://" connection. "wrs://" is intended to reduce the incidence of man-in-the-middle attack; it cannot prevent man-in-the-middle attack on client to client connections.

And The server side of "wrs://" protocol SHALL ensure the security of each link and the handling of blacklist.

5. References

5.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <>.
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <>.
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <>.
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, , <>.
Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, , <>.

5.2. Informative References

Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, , <>.
Nottingham, M., "The "secret-token" URI Scheme", RFC 8959, DOI 10.17487/RFC8959, , <>.

Appendix A. Example URIs

The content of sdp is as follows:

a=fingerprint:sha-256 B6:9E:F3:DD:8B:83:8D:F6:95:4E:76:40:AF:F2:78

The ufrag component is "Yb1d".
The pwd component is "uCiLWVRLVIKkrl14SzyO4TMF"
The basehash component before Base64 is
The basehash component is

So, the endpoint component is

Without STUN or TURN:

o  If no STUN or TURN, expressed in "wr:///". For example:

   *  "wr:///tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4EYb1duCiLWV

o  Or omit "//", expressed in "wr:/". For example:

   *  "wr:/tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4EYb1duCiLWVRL

With STUN or TURN:

o  Use STUN or TURN server, For example:

   *  "wr://

o  Use STUNs or TURNs server, For example:

   *  "wrs://


Frankly speaking, the document format refers to [RFC8959] when writing.
Thank you~

Author's Address