RFC 7890
Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)
RFC 7890: Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) 💖
Part 1 of 5 ✨
Okay bestie, this one is from June 2016 and it's an Informational doc 🎀. It came from the IETF and was written by D. Bryan (Cogent Force, LLC), P. Matthews (Nokia), E. Shim (Samsung Electronics Co., Ltd.), D. Willis (Softarmor Systems), and S. Dawkins (Huawei (USA)). It's ISSN 2070-1721, and the header doesn't list anything it obsoletes or updates 💅.
Abstract 🦋
Okay so this doc defines the concepts and terminology for using SIP in a peer-to-peer environment, where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism 🌸. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. It also gives a high-level view of how the network elements defined here relate to each other, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group 🧚.
Status of This Memo 🫶
This is not an Internet Standards Track specification. It's published for informational purposes 🍓.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🙈.
For info about the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7890 💜.
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 👑.
Table of Contents 📚
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. High-Level Description . . . . . . . . . . . . . . . . . . . 4
2.1. Services . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Relationship between P2PSIP and RELOAD . . . . . . . . . 5
2.4. Relationship between P2PSIP and SIP . . . . . . . . . . . 5
2.5. Relationship between P2PSIP and Other AoR-Dereferencing
Approaches . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . 6
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. The Distributed Database Function . . . . . . . . . . . . 12
5.2. Using the Distributed Database Function . . . . . . . . . 13
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 14
5.5. Clients and Connecting Unmodified SIP Devices . . . . . . 15
5.6. Architecture . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 191. Background 🎀
Okay, one of the fundamental problems in multimedia communication between Internet nodes is the rendezvous problem, which means figuring out which host a given user can actually be reached at 👀. In the Session Initiation Protocol (SIP) [RFC3261], this shows up as mapping an Address of Record (AoR) for a user into one or more Contact URIs [RFC3986]. The AoR is a name for the user that doesn't depend on which host or hosts the user can be contacted at, while a Contact URI points to the host where the user can be contacted. Lowkey the AoR is the "who" and the Contact URI is the "where" 💅.
In the common SIP architectures we call "Conventional SIP" or "Client/Server SIP", there's a pretty fixed hierarchy of SIP routing proxies and SIP user agents 🏛️. To deliver a SIP INVITE to the host or hosts where the user can be contacted, a SIP UA follows the procedures in [RFC3263] to find the IP address of a SIP proxy, and then sends the INVITE to that proxy. The proxy then delivers the SIP INVITE to the hosts where the user can be contacted ✈️.
This document gives a high-level description of a different solution to this problem 🦋. In this alternative, the fixed hierarchy of Client/Server SIP is replaced by a peer-to-peer overlay network. In that overlay, the mappings of AoRs to Contact URIs aren't centralized at proxy/registrar nodes. They're instead distributed among the peers in the overlay 🌸.
The details of this alternative are specified by the RELOAD protocol [RFC6940], which defines a mechanism for distribution using a Distributed Hash Table (DHT). It also specifies the wire protocol, security, and authentication mechanisms needed to convey this information 🔥. This DHT protocol was designed specifically with the purpose of enabling a distributed SIP registrar in mind. While designing it, other applications were considered, and design decisions were made that allow RELOAD to be used in other cases where a DHT is desirable, but only when those decisions didn't add undue complexity to the RELOAD protocol 🧠. The RELOAD SIP document [P2PSIP] specifies how RELOAD is used with the SIP protocol to enable a distributed, server-less SIP solution 💜.
2. High-Level Description ✨
A Peer-to-Peer SIP (P2PSIP) Overlay is a collection of nodes organized in a peer-to-peer fashion for the purpose of enabling real-time communication using the Session Initiation Protocol (SIP) 🎀. Together, the nodes in the Overlay provide a distributed mechanism for mapping names to Overlay locations. This gives the mapping of Addresses of Record (AoRs) to Contact URIs, which is how it provides the "location server" function of [RFC3261]. An Overlay also provides a transport function, so SIP messages can be carried between any two nodes in the Overlay 🚀.
A P2PSIP Overlay consists of one or more nodes called "Peers" 🫶. The nodes in the Overlay collectively run a distributed database algorithm. That algorithm lets data be stored on nodes and retrieved efficiently 🗂️. It may also make sure a copy of a data item is stored on more than one node, so losing one node doesn't mean losing the data item for the Overlay 🛟.
One use of this distributed database is storing the information needed to map AoRs to Contact URIs for the distributed location function 📍. That gives each Overlay a location function that's an alternative to the location functions described in [RFC3263]. However, the model of [RFC3263] is still used between Overlays 🌈.
2.1. Services 🧚
Peer-to-peer computing is all about each peer offering services to other peers, so the overlay can collectively provide bigger functions 🤝. In P2PSIP, Peers offer both distributed storage and distributed message-routing services, so these functions can be implemented across the Overlay 💖. RELOAD also offers a simplistic discovery mechanism specific to the Traversal Using Relays around NAT (TURN) [RFC5766] protocol, which is used for NAT traversal 🔁. Individual Peers may also offer other services as an enhancement to P2PSIP functionality (for example, to support voicemail), or to support applications beyond SIP 📫. To support these extra services, Peers may need to store additional information in the Overlay. [RFC7374] describes the mechanism P2PSIP uses for resource discovery 🔍.
2.2. Clients 🎀
An Overlay may or may not also include one or more nodes called "Clients" 🤷♀️. In RELOAD, Clients are peers that haven't joined the Overlay, so they don't route messages or store information. Clients access the services of the RELOAD protocol by connecting to a Peer that performs operations on the Client's behalf 💅. Note that RELOAD doesn't have a distinct client protocol. Instead, a Client connects using the same protocol, but never joins the Overlay as a Peer. For more info, see [RFC6940] 📖.
A special Peer may also be a member of the P2PSIP Overlay, and it may present the functionality of one or all of a SIP registrar, proxy, or redirect server to conventional SIP devices (that is, unmodified SIP user agents (UAs) or clients) 🦋. This means existing, unmodified SIP clients can connect to the P2PSIP network 🌸. Note that in the context of P2PSIP, the unmodified SIP client is sometimes also called a "client" 🙃. These unmodified SIP devices don't speak the RELOAD protocol, and this is a different concept from the "Client" we talked about in the previous paragraph 🧁.
2.3. Relationship between P2PSIP and RELOAD 💜
The RELOAD protocol, defined by the P2PSIP working group, implements a DHT primarily for use by server-less, peer-to-peer SIP deployments 💫. However, RELOAD could be used for other applications too. So a "P2PSIP" deployment is generally assumed to be a use of RELOAD to implement distributed SIP, but it's possible that RELOAD is used to distribute other applications that have nothing to do with SIP 🌟.
2.4. Relationship between P2PSIP and SIP 🫧
Since P2PSIP is about peer-to-peer networks for real-time communication, it's expected that most Peers and Clients will be coupled with SIP entities (although RELOAD may be used for applications other than P2PSIP) 📞. For example, one Peer might be coupled with a SIP UA, another with a SIP proxy, and a third with a SIP-to-PSTN gateway 🌉. For these nodes, the Peer or Client portion of the node is logically distinct from the SIP entity portion 🧩. However, there's no hard requirement that every P2PSIP node (Peer or Client) be coupled to a SIP entity. For example, additional Peers could be placed in the Overlay to provide extra storage or redundancy for the RELOAD Overlay, but they might not have any direct SIP capabilities 🍰.
2.5. Relationship between P2PSIP and Other AoR-Dereferencing Approaches ✨
okay so bestie, remember how P2PSIP's whole main quest is turning an AoR into a Contact? 💅 There are other ways people try to do that too, and they're giving serious "what if" energy 🫶
This job could be handled with zero configuration techniques like multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) [RFC6762] [RFC6763], Link-Local Multicast Name Resolution [RFC4795], and dynamic DNS [RFC2136]. 🌸
These alternatives got discussed in the P2PSIP working group, but they didn't become the general solution, and the reasons are all about scalability, working when you're disconnected, partition recovery, and more 🙈 ngl that's a lot of reasons to say no! However, there's still some lowkey interest in using mDNS and DNS-SD to bootstrap P2PSIP overlays 🦋
2.6. NAT Issues 🚧
Network Address Translators (NATs) are kind of the villains here 😭 They make it hard to set up and keep up peer-to-peer networks, because they get in the way of direct communication between nodes.
Some peer-to-peer architectures dodge this by insisting that every node lives in the same address space. Not me 🙅♀️ RELOAD is way more flexible: it lets nodes sit in multiple address spaces linked by NATs, lets RELOAD messages get through NATs, and helps carry application-level messages (like SIP messages) across NATs too. It's giving main character energy 👑
3. Reference Model 🧚
Okay, picture this diagram. It shows a P2PSIP Overlay with a bunch of Peers, one Client, and an ordinary SIP UA. It's a typical P2PSIP Overlay, but it doesn't limit other setups or variations. For example, Proxy Peer P could also talk to an ordinary SIP proxy 🎀 The figure isn't meant to cover every possible architecture. It just shows a deployment with lots of the common P2PSIP pieces.
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # RELOAD
| E | A | F | +---------+ # P2PSIP
| | T | | # Protocol
+------+ N +------+ # |
# A # |
NATNATNATNAT # | \__/
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |#####/ UA \
+------+ A P2PSIP Overlay | Peer | /Client\
| | T | Q | |___C__|
| UA | N | |
| Peer | A +-------+
| D | T #
| | N #
+------+ A # RELOAD
# T # P2PSIP
# N +-------+ +-------+ # Protocol
# A | | | | #
#########T####| Proxy |########| Redir |#######
N | Peer | | Peer |
A | P | | R |
T +-------+ +-------+
| /
| SIP /
\__/ / /
/\ / ______________/ SIP
/ \/ /
/ UA \/
/______\
SIP UA A
Figure 1: P2PSIP Overlay Reference ModelOkay, so the big # perimeter is a stylized view of the Overlay. The real connections could be a mesh, a ring, or some other structure 🌈 Around the outside of the Overlay rectangle, there are a bunch of Peers. Each Peer is labeled with its coupled SIP entity. For example, "Proxy Peer P" means Peer P is coupled with a SIP proxy. Sometimes a Peer or Client might be coupled with two or more SIP entities 💜
In this diagram, Peer "G" is coupled with a Public Switched Telephone Network (PSTN) gateway. Peers "D", "E", and "F" are each coupled with a UA. Peer "P" is coupled with a SIP proxy. Peer "Q" is an ordinary Peer with no SIP capabilities. Peer "R" is coupled with a SIP redirector. Note that because these are all Peers, each one is responsible for storing Resource Records and transporting messages around the Overlay ✨
On the left, Peers "D" and "E" are behind network address translators (NATs). They're still part of the P2PSIP Overlay, so they take part in storing resource records and routing messages, even though they're behind the NATs 🫶
On the right, there's a Client "C". It uses the RELOAD Protocol to talk to Proxy Peer "Q". The Client "C" uses RELOAD to get information from the Overlay, but it hasn't inserted itself into the Overlay. That means it doesn't participate in routing messages or storing information 🦋
Below the Overlay is a conventional SIP UA "A". It isn't part of the Overlay, either as a Peer or as a Client. It doesn't speak the RELOAD P2PSIP protocol. Instead, it uses SIP to interact with the Overlay through an adapter Peer or Peers that talk to the Overlay using RELOAD 🎀
Both the SIP proxy coupled with Peer "P" and the SIP redirector coupled with Peer "R" can act as adapters between ordinary SIP devices and the Overlay. Each one accepts standard SIP requests, uses the P2PSIP protocol to resolve the next hop through the Overlay's routing knowledge, and then processes the SIP request as appropriate, either proxying or redirecting it toward the next hop 🧚 Also, proxy operation goes both ways. The proxy might be forwarding a request from an ordinary SIP device into the Overlay, or from the P2PSIP Overlay out to an ordinary SIP device 💅
The PSTN Gateway at Peer "G" does a similar job of adapting between the Overlay and the PSTN 🌸
4. Definitions ✨
okay bestie, this section is the glossary for all of P2PSIP 📖💖 It's where we get on the same page about the words, because some of them mean different things in other networking books, and that's a whole mess we're avoiding. 🫶
Overlay Network: an overlay network is a computer network built on top of another network 🦋 Its nodes are linked by virtual or logical links, and each link maps to a path through the underlying network, which might cross lots of physical links. Lots of peer-to-peer networks are overlays because they run on top of the Internet. Dial-up Internet is an overlay on the telephone network. Iconic 👑
P2P Network: a peer-to-peer (or P2P) network is one that mostly runs on the computing power and bandwidth of its participants, instead of piling it all onto a small number of servers 🌸 P2P networks usually connect nodes through pretty ad hoc connections. They're used for a bunch of stuff. Sharing files like audio, video, data, or anything digital is super common, and real-time data like phone traffic moves over P2P tech too. A P2P Network can also be called a "P2P Overlay", a "P2P Overlay Network", or a "P2P Network Overlay". The reason is that it isn't organized at the physical layer, it sits "on top of" an existing Internet Protocol network 🧚
P2PSIP: a suite of communications protocols related to the Session Initiation Protocol (SIP) [RFC3261]. They let SIP use peer-to-peer techniques to resolve the targets of SIP requests, carry SIP messages, and handle other SIP-related jobs 💅 Right now the protocols include [RFC6940], [RFC7363], [RFC7374], [RFC7851] and [P2PSIP].
User: a human who interacts with the Overlay through SIP UAs that sit on Peers and Clients (and maybe in other ways too) 🌈
The following terms are only defined here, within the scope of P2PSIP. They might mean something different in other bodies of literature 🙈 Some draft versions of this document put "P2PSIP" in front of each term to make the scope clear. That prefix got dropped from the text, but the scoping still applies, so keep it in mind 💜
Overlay Name: a human-friendly name that identifies a specific P2PSIP Overlay. It's formatted like (a portion of) a URI, and it may or may not have a matching record in the DNS 🎀
Peer: a node in a P2PSIP Overlay that provides storage and transport services to the other nodes in that Overlay 💖 Each Peer has a unique identifier called a Peer-ID inside the Overlay. A Peer can be coupled to one or more SIP entities. Inside the Overlay, a Peer can do a bunch of things: join and leave the Overlay, transport SIP messages, store information for the Overlay, put information into the Overlay, and get information from it. Main character energy ✨
Node-ID: information that uniquely identifies each Node within a given Overlay. It isn't human-friendly. In a DHT approach, it's a numeric value in the hash space 🔢 Node-IDs are completely independent of the identifier of any user of a user agent associated with a Peer.
Client: a node that takes part in a P2PSIP Overlay but doesn't store information or forward messages 🦋 You can also think of a Client as a peer that hasn't joined the Overlay. Clients can still store and retrieve information from the Overlay 🫧
User Name: a human-friendly name for a user. It has to be unique within the Overlay, though it might be unique in a wider scope too. User Names are formatted so they can go inside a URI (probably a SIP URI), maybe combined with the Overlay Name 💌
Service: a capability a Peer contributes to an Overlay or to its members. Not every Peer and Client offers the same services, and P2PSIP has service discovery mechanisms to help find them 🔍
Service Name: a unique, human-friendly name for a service 🏷️
Resource: anything about which information can be stored in the Overlay. Both Users and Services count as Resources 🌸
Resource-ID: a non-human-friendly value that uniquely identifies a resource and is used as the key for storing and retrieving data about it. One way to make a Resource-ID is to run some other unique name for the resource, like a User Name or Service Name, through a mapping function. The distributed database algorithm uses the Resource-ID to figure out which Peer or Peers are responsible for storing the Overlay's data 🧠
Resource Record: a block of data, stored with the Overlay's distributed database mechanism, that holds information about a specific resource 📦 There might be multiple types of resource records. Some could hold data about Users, others about Services, and the working group could define more types. The types, usages, and formats of the records are a question for future study 🔮
Responsible Peer: the Peer responsible for storing the Resource Record for a Resource. In the literature, "Root Peer" is also used for this idea 👑
Peer Protocol: the protocol Peers in a P2PSIP Overlay speak to share information and organize the P2PSIP Overlay Network. In P2PSIP, it's implemented using the RELOAD protocol [RFC6940] 🛠️
Client Protocol: the protocol spoken between Clients and Peers. In P2PSIP and RELOAD, it's syntactically the same protocol as the Peer Protocol. The only difference is that Clients don't route messages or routing information, and they haven't (or can't) insert themselves into the Overlay 🫶
Peer Protocol Connection / P2PSIP Client Protocol Connection: the Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), TCP, UDP, or other transport-layer protocol connection that carries RELOAD Peer Protocol messages 🚇
Neighbors: the set of P2PSIP Peers that a Peer or Client knows about directly and can reach without doing any further lookups 🤝
Joining Peer: a node trying to become a Peer in a particular Overlay 🥹
Bootstrap Peer: a Peer in the Overlay that's the first point of contact for a Joining Peer. It picks the Peer that will act as the Admitting Peer and helps the Joining Peer reach that Admitting Peer 🚪
Admitting Peer: a Peer in the Overlay that helps the Joining Peer join. Which Admitting Peer gets picked can depend on the Joining Peer (for example, on the Joining Peer's Peer-ID). For instance, the Admitting Peer might be the Peer that's "closest" in the Overlay's logical structure to where the Joining Peer will sit. The Bootstrap Peer usually makes this choice. It's allowed for the Bootstrap Peer to pick itself as the Admitting Peer 🎯
Bootstrap Server: a network node that Joining Peers use to locate a Bootstrap Peer. A Bootstrap Server can act as a proxy for messages between the Joining Peer and the Bootstrap Peer. It's usually a stable host with a DNS name that gets passed to Peers wanting to join the Overlay somehow, like through configuration, a web page, or DHCP 🌐 A Bootstrap Server is NOT required to be a Peer or Client, though it can be if you want 💅
Peer Admission: the act of admitting a node (the "Joining Peer") into an Overlay as a Peer. Once admission is done, the Joining Peer is a fully functional Peer of the Overlay 🎉 During admission, the Joining Peer might need to show credentials proving it has enough authority to join 🔐
Resource Record Insertion: the act of inserting a P2PSIP Resource Record into the distributed database. After insertion, the data gets stored at one or more Peers. The data can be retrieved or updated using the Resource-ID as a key 📥
5. Discussion 💅
5.1. The Distributed Database Function 🗄️
okay so, a P2PSIP Overlay works as a distributed database 🫧 It's a place to store information about Resources. A piece of information, called a "Resource Record", can be stored in and retrieved from the database using a key tied to that record, called its "Resource-ID". Every Resource needs its own unique Resource-ID. Besides identifying the Resource, the Resource-ID is also what the distributed database algorithm uses to figure out which Peer or Peers store the Resource Record in the Overlay 🔑
Users are humans who can use the Overlay to do things like making and receiving calls 📞 The information in a user's resource record can include stuff like their full name and the locations of the UAs they're using (the user's SIP AoR). How this works in RELOAD is spelled out in [P2PSIP] 💜
Before any info about a user can go into the Overlay, the user needs a User Name. It's a human-friendly identifier that uniquely identifies the user within the Overlay 🌷 In RELOAD, users get certificates. For centrally signed certificates, those identify the User Name plus a certain number of Resource-IDs where the user can store their information. For more, see [RFC6940] 🎀
P2PSIP also standardizes how to locate services 🔍 Services are actions a Peer (and maybe a Client) can perform to help other Peers and Clients in the Overlay ✨ The information in a service's resource record might include the Peers (and maybe Clients) that offer that service. Service discovery for P2PSIP is defined in [RFC7374] 🧚
Each service has a human-friendly Service Name that uniquely identifies it 🏷️ Just like User Names, the Service Name isn't a Resource-ID. The Resource-ID gets derived from the service name using a function that the Overlay's distributed database algorithm defines 🧮
Distributed Hash Tables (DHTs) are one way to build the distributed database 🌈 RELOAD is extensible and lets lots of different DHTs get implemented, but it specifies one mandatory-to-implement DHT, a modified Chord DHT. For more info, see [Chord] 🦋
5.2. Using the Distributed Database Function ✨
okay so there are a bunch of ways the distributed database from the last bit can be used to set up multimedia sessions with SIP 📞, but the basic mechanism is what RELOAD and SIP usage cook up together. ngl this is a super simplified overview, so if you want the full tea, go read the RELOAD protocol [RFC6940] 📚
Contact info for a user lives in that user's resource record 🗂️. Say a user is on a device we'll call "Peer A", which is their contact point. The user adds their contact info to the resource record, and RELOAD's certificate mechanism is what says they're allowed to do that 🔐. The resource record itself gets stored with Peer Z, and Peer Z is picked by whatever distributed database algorithm the Overlay is running 🧚
Now when the SIP entity hooked up to Peer B gets an INVITE addressed to this user, it fetches the resource record from Peer Z 💌. Then it pulls out the contact info for all the Peers that are contact points for the user, Peer A included, and uses the Overlay to connect to Peer A 🦋. Any NAT traversal that's needed happens here too (the details aren't shown, bestie) 🙈
Here's the main thing: RELOAD is only used to establish the connection 💜. Once that's up, the Peers just send ordinary SIP messages to each other 💅
Here's the whole exchange as a picture 🎀. "Store(U@A)" means the distributed database is updating user U's resource record with contact A, and "Fetch(U)" means it's grabbing the resource record for user U. Also, the messages between Peers A, B, and Z might actually hop through other Peers (not drawn) for the distributed lookup, or to get past NATs in the way 🌸
Peer B Peer Z Peer A
| | |
| | Store(U@A)|
| |<------------------|
| |Store-Resp(OK) |
| |------------------>|
| | |
|Fetch(U) | |
|------------------->| |
| Fetch-Resp(U@A)| |
|<-------------------| |
| | |
(RELOAD IS USED TO ESTABLISH CONNECTION)
| | |
| SIP INVITE(To:U) | |
|--------------------------------------->|
| | |Figure 2: SIP Exchange Using Distributed Database Function
5.3. NAT Traversal 🧗♀️
NAT traversal in P2PSIP using RELOAD treats every Peer as equal 👑, and it sets up a partial mesh of connections between them. When one Peer messages another, the message gets routed along the edges of that mesh until it arrives 💫. To keep routing efficient and avoid leaning on standard Internet routing protocols, the partial mesh is organized in a structured way 🧩. If the structure is based on any one of a bunch of common DHT algorithms, then the max number of hops between any two Peers is log N, where N is the number of peers in the overlay 📐. Existing connections, plus the Interactive Connectivity Establishment (ICE) NAT traversal techniques [RFC5245], are used to set up new connections between Peers 🤝. They also let the applications running on Peers connect and talk to each other 💖
5.4. Locating and Joining an Overlay 🚪
Before a Peer can try to join a P2PSIP Overlay, it has to get a Node-ID, configuration info, and optionally a set of credentials 🎫. The Node-ID is an identifier that uniquely identifies the Peer within the Overlay, and the credentials prove the Peer is allowed to join ✨
The P2PSIP WG doesn't force one particular way for the Peer-ID and credentials to be obtained 🤷♀️. But the RELOAD protocol does specify the format of the configuration info, and how that info can be obtained, along with credentials and a Node-ID, from an offline enrollment server 🌈
Once the config info is in hand, RELOAD specifies a way for a Peer to get a multicast-bootstrap address from the configuration file and broadcast to that address to try finding a Bootstrap Peer 📡. The Peer can also store Peers it's seen before and try using those as Bootstrap Peers, or it can get a Bootstrap Peer address some other way 🗺️. For more info, see the RELOAD protocol 📖
The Bootstrap Peer's job is pretty simple: point the Joining Peer to a Peer (called the "Admitting Peer") who'll help them join the network 🫶. Which Admitting Peer gets picked often depends on the Joining Peer. For example, the Admitting Peer might be a Peer who's going to become a neighbor of the Joining Peer in the Overlay 🏡. It's also possible that the Bootstrap Peer is the Admitting Peer too 🔄
The Admitting Peer helps the Joining Peer learn about other Peers in the Overlay and set up connections to them where it makes sense 🕸️. The Admitting Peer and/or the other Peers in the Overlay also do whatever else is needed to make the Joining Peer a fully functional Peer 💅. How all that goes down depends on the distributed database algorithm the Overlay uses 🧠
At different points in this process, the Joining Peer might be asked to show its credentials, to prove it's authorized to join the Overlay 🔑. And the Peers it contacts might be asked to show their credentials too, so the Joining Peer can double-check it's really joining the Overlay it meant to 🕵️♀️
5.5. Clients and Connecting Unmodified SIP Devices 📱
As I said earlier, in RELOAD, from the protocol's point of view, Clients are just peers that don't store info, don't route messages, and haven't inserted themselves into the Overlay 🙃. The same protocol is used for the actual messages being exchanged 💬. But even though the protocol is the same, a Client doesn't need to implement every capability a Peer has. If it never routes messages, for instance, it doesn't need to be able to process those messages or understand a DHT 🫠
For SIP devices, there's another way to get this functionality: a Peer can act as a proxy/registrar as specified in [RFC3261] 🎀. SIP devices can then use standard SIP mechanisms to add, update, and remove registrations, and to send SIP messages to Peers and other Clients 📨. The authors refer to these devices simply as a "SIP UA", not a "P2PSIP Client", to tell them apart from the concept we just talked about 🦋
5.6. Architecture 🏗️
Here's the architecture RELOAD uses to implement P2PSIP 🌸. An application (like SIP, or another app using RELOAD) uses RELOAD to locate other Peers and, optionally, to set up connections to them, possibly across NATs 🧚♀️. Messages can still be exchanged directly between the Peers 💜. Here's the overall block diagram:
__________________________
| |
| SIP, other apps... |
| ___________________|
| | RELOAD Layer |
|______|___________________|
| Transport Layer |
|__________________________|Figure 3: Architecture for Implementing P2PSIP
6. Security Considerations 🚨
This specification is an overview of existing specifications, and it doesn't introduce any security considerations on its own 🙏. Please check the security considerations of the respective specifications, especially the RELOAD protocol specification ([RFC6940]), for the full scoop 😭🔐
7. Informative References ✨
Okay bestie, last stretch! 🎀 This is the bibliography, aka every source this spec leaned on. Citations are sacred, so every entry is copied exactly as written, down to the DOIs and dates 🫶
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
scalable peer-to-peer lookup protocol for internet
applications", IEEE/ACM Transactions on Networking,
Volume 11, Issue 1, pp. 17-32,
DOI 10.1109/TNET.2002.808407, February 2003.
[P2PSIP] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
Work in Progress, draft-ietf-p2psip-sip-21, April 2016.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<http://www.rfc-editor.org/info/rfc3263>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
DOI 10.17487/RFC4795, January 2007,
<http://www.rfc-editor.org/info/rfc4795>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed
Hash Table (DHT) for REsource LOcation And Discovery
(RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014,
<http://www.rfc-editor.org/info/rfc7363>.
[RFC7374] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)", RFC 7374,
DOI 10.17487/RFC7374, October 2014,
<http://www.rfc-editor.org/info/rfc7374>.
[RFC7851] Song, H., Jiang, X., Even, R., Bryan, D., and Y. Sun,
"Peer-to-Peer (P2P) Overlay Diagnostics", RFC 7851,
DOI 10.17487/RFC7851, May 2016,
<http://www.rfc-editor.org/info/rfc7851>.Authors' Addresses 💜
Now the squad behind this doc! 👑 Here's how to reach each of them, copied exactly so nothing gets lost in translation 🦋
David A. Bryan
Cogent Force, LLC
Cedar Park, Texas
United States
Email: dbryan@ethernot.org
Philip Matthews
Nokia
600 March Road
Ottawa, Ontario K2K 2E6
Canada
Phone: +1 613 784 3139
Email: philip_matthews@magma.ca
Eunsoo Shim
Samsung Electronics Co., Ltd.
San 14, Nongseo-dong, Giheung-gu
Yongin-si, Gyeonggi-do 446-712
South Korea
Email: eunsooshim@gmail.com
Dean Willis
Softarmor Systems
3100 Independence Pkwy #311-164
Plano, Texas 75075
United States
Phone: +1 214 504 1987
Email: dean.willis@softarmor.com
Spencer Dawkins
Huawei Technologies (USA)
Phone: +1 214 755 3870
Email: spencerdawkins.ietf@gmail.comThat's the whole spec, bestie! 🌈✨ You absolutely slayed this document 💅🫶
📦 where this page comes from
- ietf: rfc7890 2016-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms