idnits 2.17.1 draft-willis-p2psip-concepts-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1225. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1153 has weird spacing: '...ologies and C...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2006) is 6393 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1095, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-02 == Outdated reference: A later version (-01) exists of draft-irtf-p2prg-survey-search-00 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-11 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 (Proposed) P2PSIP Working Group D. Bryan 3 Internet-Draft SIPeerior Technologies and 4 Intended status: Informational College of William and Mary 5 Expires: April 25, 2007 P. Matthews 6 Avaya 7 E. Shim 8 Panasonic Digital Networking Lab 9 D. Willis 10 Cisco Systems 11 October 22, 2006 13 Concepts and Terminology for Peer to Peer SIP 14 draft-willis-p2psip-concepts-03 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 25, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document defines concepts and terminology for use of the Session 48 Initiation Protocol in a peer-to-peer environment where the 49 traditional proxy-registrar function is replaced by a distributed 50 mechanism that might be implemented using a distributed hash table or 51 other distributed data mechanism with similar external properties. 52 This document includes a high-level view of the functional 53 relationships between the network elements defined herein, a 54 conceptual model of operations, and an outline of the related open 55 problems that might be addressed by an IETF working group. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [1]. 63 Table of Contents 65 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.1. What Kinds of P2PSIP Peers and Clients Might Exist? . . . 10 71 3.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 11 72 3.3. The P2PSIP protocols . . . . . . . . . . . . . . . . . . . 14 73 3.4. Example Signalling Message Flows . . . . . . . . . . . . . 15 74 3.4.1. P2PSIP Peer contacts P2PSIP Peer . . . . . . . . . . . 15 75 3.4.2. P2PSIP Client contacts P2PSIP Peer . . . . . . . . . . 16 76 3.4.3. Conventional SIP Device using a Proxy Peer . . . . . . 18 77 3.4.4. Conventional SIP Device Using a Redirect Peer . . . . 19 78 3.5. Conceptual Outline of Operations . . . . . . . . . . . . . 21 79 3.5.1. Enrolling and Inserting an P2PSIP Peer . . . . . . . . 21 80 3.5.2. More on The Difference Between a Peer, Client, and 81 User Agent . . . . . . . . . . . . . . . . . . . . . . 22 82 3.5.3. Enrolling a User and Inserting a P2PSIP User Agent . . 23 83 3.5.4. Bootstrapping . . . . . . . . . . . . . . . . . . . . 23 85 4. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 4.1. PP2PSIP Peer Protocol . . . . . . . . . . . . . . . . . . 24 87 4.2. P2PSIP Client Protocol . . . . . . . . . . . . . . . . . . 25 88 4.3. How Do We Find Gateways? . . . . . . . . . . . . . . . . . 25 89 4.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 25 90 4.5. Cryptotransparency . . . . . . . . . . . . . . . . . . . . 25 91 4.6. Record Formats . . . . . . . . . . . . . . . . . . . . . . 26 92 4.7. Peer and Client Enrollment Protocols . . . . . . . . . . . 26 93 4.8. Peer and User Credentials . . . . . . . . . . . . . . . . 26 94 4.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26 95 4.10. Credential Recovery . . . . . . . . . . . . . . . . . . . 26 96 4.11. Overlapping Domains . . . . . . . . . . . . . . . . . . . 26 97 4.12. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 27 98 4.13. Admissions Control . . . . . . . . . . . . . . . . . . . . 27 99 4.14. Users versus Resources . . . . . . . . . . . . . . . . . . 27 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 107 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 109 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 112 Intellectual Property and Copyright Statements . . . . . . . . . . 31 114 1. Background 116 One of the fundamental problems in multimedia communications between 117 Internet nodes is that of a discovering the IP address at which a 118 given correspondent can be reached. Correspondents are frequently 119 identified by distinguished names, perhaps represented in the form of 120 a universal resource indicator (URI) [2]. 122 The Session Initiation Protocol (SIP) [3] commonly addresses this 123 task assuming that the domain part of the URI indicates an internet 124 host address or internet domain name using the Domain Name System 125 (DNS) [4]. SIP's location process [5] assumes that the host part of 126 the URI indicates either the target SIP user agent (UA), or a proxy 127 that has knowledge of how to to reach the target UA, presumably 128 gained through SIP's registration process. 130 This approach, referred to herein as "Conventional SIP" or "Client/ 131 Server SIP", assumes a relatively fixed hierarchy of SIP routing 132 proxies (servers) and SIP user agents (clients). The routing proxies 133 are typically resolvable using conventional Internet mechanisms with 134 static IP addresses and associated DNS entries. This structure may 135 not be ideal in all cases, including specifically ad-hoc, serverless, 136 and reduced-administration scenarios. As an alternative, several 137 authors [7] [8] [9] [10] have proposed using peer-to-peer (P2P) [11] 138 approaches to solving the problem of locating the correspondent. The 139 motivations for a P2P approach in SIP have been documented in [12]. 141 This document offers a consolidation of the more important terms and 142 concepts from several of the above documents, presented in the 143 context of a reference model for peer-to-peer SIP (P2PSIP). It is 144 intended that this document serve as a starting point for describing 145 the work needed to resolve a number of open questions such that an 146 IETF working group could be chartered to do the work needed to 147 resolve these questions and present a standard solution. The authors 148 believe that this goal is roughly consistent with that of a Protocol 149 Model as defined in [13]. 151 2. Definitions 153 This section defines a number of concepts that are key to understand 154 the P2PSIP work. 156 OPEN ISSUE: There is still much debate around the names attached 157 to some of these concepts. (For now, the recommendation is to 158 concentrate on the concepts and not worry too much about the 159 names). 161 Overlay Network: An overlay network is a computer network which is 162 built on top of another network. Nodes in the overlay can be 163 thought of as being connected by virtual or logical links, each of 164 which corresponds to a path, perhaps through many physical links, 165 in the underlying network. For example, many peer-to-peer 166 networks are overlay networks because they run on top of the 167 Internet. Dial-up Internet is an overlay upon the telephone 168 network. 170 P2P Network: A peer-to-peer (or P2P) computer network is a network 171 that relies primarily on the computing power and bandwidth of the 172 participants in the network rather than concentrating it in a 173 relatively low number of servers. P2P networks are typically used 174 for connecting nodes via largely ad hoc connections. Such 175 networks are useful for many purposes. Sharing content files (see 176 file sharing [18]) containing audio, video, data or anything in 177 digital format is very common, and realtime data, such as 178 telephony traffic, is also passed using P2P technology. 179 . A P2P Network may 180 also be called a "P2P Overlay" or "P2P Overlay Network" or "P2P 181 Network Overlay" , since its organization is not at the physical 182 layer, but is instead "on top of" an existing Internet Protocol 183 network. 185 P2PSIP: A suite of communications protocols related to the Session 186 Initiation Protocol (SIP) [3] that extends SIP by using peer-to- 187 peer techniques for resolving the targets of SIP requests. The 188 exact contents of this protocol suite are still under discussion, 189 but is likely to include the P2PSIP Peer Protocol and the P2PSIP 190 Client Protocol (see definitions below). 192 P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or 193 federation of nodes that provides SIP registration, SIP request 194 routing, and similar functions using a P2P organization, as 195 defined by "P2P Network" above. 197 P2PSIP Peer: A node participating in a P2PSIP Overlay that provides 198 storage and routing services (fully participates in the P2P 199 routing) to other nodes in that P2PSIP Overlay. Each P2PSIP Peer 200 is presumed to have a unique identifier within the P2PSIP Overlay. 201 Each P2PSIP Peer may or may not be coupled to one or more P2PSIP 202 User Agents. Within the P2PSIP Overlay, the peer is capable of 203 performing several different operations, including: joining and 204 leaving the overlay, routing requests within the overlay, storing 205 information on behalf of the overlay, putting information into the 206 overlay, and getting information from the overlay. A notable 207 property of P2PSIP Peers is that they can be fully functional 208 peers while residing behind NATs. Contrast this with some other 209 P2P systems which make a distinction between "peer" and "super- 210 peer" (or "node" and "super-node") where the latter must have a 211 public IP address. 213 P2PSIP Client: A node participating in a P2PSIP Overlay that 214 provides neither routing nor route storage and retrieval functions 215 to that P2PSIP Overlay. The P2PSIP Client interacts with the 216 P2PSIP Overlay by having an association (details TBD) with one or 217 more P2PSIP peers. Using these peers, the client can request the 218 insertion of routing information (put in a Contact), or request 219 the retrieval of routing information (get a Contact). Unlike the 220 P2PSIP Peer, the client is presumed not to have a unique 221 identifier within the overlay. In cases where conventional SIP is 222 used for the P2PSIP Client protocol, this entity could be 223 identical to a standard SIP entity (e.g., user agent or proxy or 224 ...). A P2PSIP Client is a logical subset of a P2PSIP Peer; 225 anything a P2PSIP Client can do, a P2PSIP Peer can do as well. 226 Note that a P2PSIP Client is not necessarily a SIP UAC. 228 OPEN ISSUE: The name for this concept is very much under 229 debate. It conflicts with the usage of this name in SIP, and 230 it suggest that a peer should be called a "server". 232 P2PSIP Resource (User): An addressable user endpoint, entity, 233 service, or function within a P2PSIP Overlay. Examples include 234 but are not limited to humans, automata, bridges, mixers, media 235 relays, gateways, and media storage. 237 OPEN ISSUE: There is still a lot of uncertainty and debate 238 around the difference, if any, between a "resource" and a 239 "user". Even this document (which is the product of multiple 240 authors) is inconsistent, sometimes treating them as more or 241 less the same thing, and sometimes treating them as distinct 242 concepts. 244 P2PSIP Overlay Identifier: Information that identifies a specific 245 P2PSIP Overlay. All the P2PSIP Peers in a particular P2PSIP 246 Overlay have the same P2PSIP Overlay Identifier. This is may be 247 scoped to a name within the DNS, but other scopes may apply, 248 particularly in ad-hoc environments. 250 P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP 251 Peer within a given P2PSIP Overlay. This value is not human- 252 friendly -- in a DHT approach, this is a numeric value in the hash 253 space. These Peer-IDs are completely independent of the 254 identifier of any user of a user agent associated with a peer. 255 (Note: This is often called a "Node-ID" in the P2P literature). 257 P2PSIP Resource (User) Name: A distinguished, human readable name 258 that identifies a specific P2PSIP Resource or User within a given 259 P2PSIP Overlay. This is presumed to be a URI scoped to the P2PSIP 260 Overlay Identifier. This is presumably the same or very similar 261 to a SIP Address of Record, or AOR. 263 P2PSIP Resource-ID: A non-human friendly value that uniquely 264 determines which P2PSIP Peer is responsible for storing 265 information about this resource (user). In a DHT approach, this 266 is a numeric value in the hash space resulting from hashing the 267 P2PSIP Resource Name. Since Resource-ID is in the same space as 268 the P2PSIP Peer-ID, it allows for a mapping between the values, 269 used to map a P2PSIP Resource to the P2PSIP Peer that stores it. 271 P2PSIP Resource (User) Record: A block of data, stored using the 272 data mechanism of the P2PSIP Overlay, that includes information 273 relevant to a specific resource. We presume that there may be 274 multiple types of resource records. Some may describe routes to a 275 P2PSIP Peer or Client at which the user or resource is presumed 276 reachable (e.g., a "user routing record" like a SIP "Contact:"). 277 Others might store presence information. The types, usages, and 278 formats of the records are a question for future study. 280 P2PSIP User Agent (UA): A SIP user agent (UA) that is coupled with 281 or incorporates a P2PSIP Peer or P2PSIP Client, such that the peer 282 or client can assist the UA with registration (storage of a route 283 to users of the UA) and/or routing of requests using the P2PSIP 284 Overlay. A P2PSIP User Agent differs from a conventional SIP user 285 agent in that it is coupled directly to a P2PSIP Peer or P2PSIP 286 Client, and can therefore directly interact with a P2PSIP Overlay, 287 which a conventional SIP UA cannot do. P2PSIP User Agents do not 288 themselves have a distinguished name or identifier, although the 289 P2PSIP User associated with it may, and if it is associated with a 290 P2PSIP Peer, that peer may as well. 292 P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay 293 peers to share information and organize the P2PSIP Overlay 294 Network. 296 P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients 297 and the P2PSIP Peer they use to store or retrieve information from 298 the P2P Overlay. This is a functional subset of the P2P Peer 299 Protocol, but may differ in syntax and protocol implementation 300 (i.e., may not be syntactically related). Note that the precise 301 relationship between the P2PSIP Peer Protocol and the P2PSIP 302 Client Protocol (the same? subset?) remains an open question and 303 is expected to be a principle topic of the detailed design work. 304 This protocol may not exist (it may simply be conventional SIP) in 305 some designs. 307 P2PSIP Neighbors: The set of P2PSIP Peers that either a P2PSIP Peer 308 or P2PSIP Client know of directly and can reach without further 309 lookups. 311 P2PSIP Bootstrap Peer: A P2PSIP Peer in the P2PSIP Overlay which is 312 willing to help new Peers join the Overlay or help new Clients 313 find Peers to associate with. A node that wishes to become a Peer 314 or Client contacts a P2PSIP Bootstrap Peer and, with the help this 315 Bootstrap Peer, gets the information it requires to become a fully 316 functioning Peer or Client (the details of this process is still 317 TBD). The new Peer or Client may locate a P2PSIP Bootstrap Peer 318 through multicast, though a P2PSIP Bootstrap Server, or through 319 other means. 321 P2PSIP Bootstrap Server: A network node used by other nodes which 322 are attempting to contact a P2PSIP Bootstrap Peer. It may return 323 the address of a P2PSIP Bootstrap Peer, or act as a proxy to relay 324 messages to and from the Bootstrap Peer, or act as a Bootstrap 325 Peer itself. The P2PSIP Bootstrap Peer itself should be a fairly 326 stable and well-known host. To be useful, there must be an easy 327 way to other nodes to locate it -- one way this might happen is 328 for it to have a well-known DNS entry. A P2PSIP Bootstrap Server 329 may or may not also be a P2PSIP Peer or P2PSIP Client in one or 330 more P2PSIP Overlays. 332 P2PSIP Peer Insertion: The act of inserting a P2PSIP Peer into the 333 current routing structure (presumably a distributed database or 334 hash table) of a P2PSIP Overlay. For example, the routing 335 structure map the peer's IP address or DNS name to the peer's 336 P2PSIP Peer-ID. During insertion, the peer discovers its P2PSIP 337 Overlay neighbors. Following insertion, the peer will be able to 338 store user records (such as routing information), query other 339 peers for user records, and pass requests to route messages to 340 other peers. During the insertion process, the overlay may 341 challenge the peer to prove that it is really allowed to insert 342 itself into the overlay. (Note: In the P2P literature, this 343 operation is often called "joining" or "registering" with the 344 overlay). 346 OPEN ISSUE: Some people are proposing that the name for this 347 concept should be "P2PSIP Peer Admission" to better capture the 348 fact that the Overlay can reject the peer if it does not have 349 the correct credentials. 351 P2PSIP Resource (User) Record Insertion: The act of inserting a 352 record for a P2PSIP Resource (User) into the data maintained by 353 the P2PSIP Peers. Following insertion, the data stored at one or 354 more peers will contain a record (such as a P2PSIP Resource 355 Routing Record), keyed at least in part by a P2PSIP User 356 Identifier. 358 P2PSIP Peer Enrollment: The initial one-time process a P2PSIP Peer 359 follows to obtain an identifier and credentials, if any, within a 360 P2PSIP Overlay. This is not performed each time the peer comes 361 online (contrast to P2PSIP Peer Insertion above), but only the 362 first time they do so, or following a loss of identifier or 363 credentials by the peer. 365 P2PSIP Resource (User) Enrollment: The initial one-time process a 366 P2PSIP Resource follows to obtain a unique identifier within a 367 P2PSIP Overlay. This is not performed each time the resource 368 comes online, only the first time they do so, or following a loss 369 of identifier or credentials by the client (contrast to P2PSIP 370 Resource Record Insertion). 372 3. Discussion 374 3.1. What Kinds of P2PSIP Peers and Clients Might Exist? 376 In general, P2PSIP nodes might have the same sorts of duties/logical 377 roles as traditional client-server SIP nodes. This includes but is 378 not limited to: 380 1. User Agent: a phone, voice mail server, bridge, or other device 381 that initiates or terminates session requests. This could be a 382 P2PSIP Client (only performs GET/PUT of data) or P2PSIP Peer 383 (participates in storing data as well) 385 2. Media relay: a P2PSIP peer or client capable of relaying media 386 sessions. For example, an RTP relay as described in [14] 388 3. Gateway: a P2PSIP peer or client that converts from P2PSIP to 389 some other protocol, such as PSTN (Public Switched Telephone 390 Network). 392 4. Redirector: a P2PSIP peer or client that accepts SIP requests 393 (such as INVITE) for a P2PSIP resource identifier, searches the 394 overlay, and returns the route to the resource in a 302 or 305 395 response. 397 5. Proxy: a P2PSIP peer or client that accepts SIP requests (such as 398 INVITE) for a P2PSIP resource identifier, searches the overlay, 399 and forwards (proxies) the request to that resource. 401 6. Registrar: A peer or client that processes SIP REGISTER requests 402 from non-P2P aware entities, either storing or retrieving the 403 contact information to/from the routing data of the P2PSIP 404 Overlay. 406 3.2. Reference Model 408 The following diagram depicts a reference or "boxes and arrows" model 409 showing several of the above peer and client types, along with a 410 conventional SIP user agent. 412 --->PSTN 413 +------+ N +------+ +---------+ / 414 | | A | | | Gateway |-/ 415 | UA |####T#####| UA |#####| Peer |######## 416 | Peer | N | Peer | | G | # P2PSIP 417 | E | A | F | +---------+ # Client 418 | | T | | # Protocol 419 +------+ N +------+ # | 420 # A # | 421 NATNATNATNAT # | 422 # # | \__/ 423 NATNATNATNAT +-------+ v / \ 424 # N | |=====/ UA \ 425 +------+ A P2PSIP Overlay | | /Client\ 426 | | T | Peer | |___C__| 427 | UA | N Route Data | Q | 428 | Peer | A +-------+ 429 | D | T P2PSIP Peer Protocol # 430 | | N # 431 +------+ A # 432 # T # 433 # N +-------+ +-------+ # 434 # A | | | | # 435 #########T####| Proxy |########| Redir |####### 436 N | Peer | | Peer | 437 A | P | | R | 438 T +-------+ +-------+ 440 \__/ 441 /\ 442 / \ 443 / UA \ 444 /______\ 445 SIP UA A 447 Figure: P2PSIP Overlay Reference Model 449 Here, the large perimeter depicted by "#" represents a stylized view 450 of the P2PSIP Overlay and its associated routing data (the actual 451 connections could be a mesh, ring, or some other structure). Around 452 the periphery of the P2PSIP Overlay rectangle, we have a number of 453 P2PSIP Peers -- a PSTN gateway peer "G", three user-agent peers "D", 454 "E" and "F", two proxy peers "P" and "Q", and a redirector peer "R". 455 Note that because these are all P2PSIP Peers, each is responsible for 456 helping store some information of the P2PSIP Overlay. 458 To the left, two of the peers ("D" and "E") are behind network 459 address translators. These peers are included in the P2PSIP overlay 460 and thus participate in storing information, despite being behind the 461 NATs. 463 Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is 464 not part of the P2PSIP Overlay, either directly as a peer or 465 indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP 466 Client protocols. Instead, it uses pure (unmodified/extended) SIP to 467 interact with with the P2PSIP Overlay. 469 On the right side, we have a P2PSIP UA client "C", which uses the 470 P2PSIP Client Protocol depicted by "=" to communicate with Proxy Peer 471 "Q". The P2PSIP Client protocol only allows for gets and puts to the 472 overlay. Therefore, "C" does NOT participate directly in/store 473 information in the overlay. In a solution where the P2PSIP Client 474 Protocol is SIP, such as is proposed in [7], there may no difference 475 between UA client "C" and standard SIP UA "A". 477 Note that in some scenarios, the P2PSIP Peers involved in the overlay 478 might use a keepalive mechanism to ensure that messages to neighbors 479 can pass through NATs. Presumably, these messages will be in the 480 form of the P2PSIP Peer protocol. 482 Both the "Proxy Peers" and "Redirect Peers" can serve as adapters 483 between ordinary SIP devices and the the P2PSIP Overlay. Each 484 accepts standard SIP requests and resolves the next-hop by using the 485 P2PSIP overlay Peer Protocol to interact with the routing knowledge 486 of the P2PSIP Overlay, then processes the SIP requests as appropriate 487 (proxying or redirecting towards the next-hop). Note that proxy 488 operation is bidirectional - the proxy may be forwarding a request 489 from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP 490 overlay to an ordinary SIP device. 492 The Gateway Peer provides a similar sort of adaptation to and from 493 the public switched telephone network (PSTN). However, there is a 494 subtle distinction. The gateway function itself can be viewed as a 495 "user" or within the P2PSIP overlay, and is addressed using a P2PSIP 496 Overlay User Identifier. This gateway functionality could also be 497 located in a P2PSIP Client, or even in a traditional SIP UA that is 498 reached via P2P (using a P2P proxy or redirector) or conventional SIP 499 mechanisms. 501 The functions of various types of peers (redirect, UA, proxy, 502 gateway) are logical roles. There is no reason a particular 503 implementation could not support one, several, or all of these 504 functions in one entity. For clarity, we show each as a fully 505 distinct entity. 507 3.3. The P2PSIP protocols 509 This document describes two new protocols: the P2PSIP Peer Protocol 510 and the P2PSIP Client Protocol. 512 The P2PSIP Peer Protocol is spoken between peers. The details of 513 this protocol are TBD, but the protocol needs to support, at a 514 minimum, the following actions: 516 o Enrolling a Peer in the Overlay 518 o Inserting a P2PSIP Peer into the Overlay 520 o Enrolling a Resource or User in the Overlay 522 o Inserting a Resource or User into the Overlay 524 o Retrieve information about a Resource or User from the Overlay 526 The P2PSIP Client Protocol is spoken between a Client and a Peer. It 527 is used by the Client to request service from the P2PSIP Overlay. 528 This protocol is logically a subset of the Peer protocol, in that the 529 actions that it supports are a strict subset of the actions supported 530 by the Peer Protocol. These actions are: 532 o Enrolling a Resource or User in the Overlay 534 o Inserting a Resource or User into the Overlay 536 o Retrieve information about a Resource or User from the Overlay 538 The details of the Client Protocol are also TBD. Some people have 539 proposed that the Client Protocol could be SIP. 541 Finally, it should be re-iterated that the Client Protocol is a 542 strict subset of the Peer Protocol (at least logically, the two may 543 differ syntactically). This has two consequences: 545 o A peer can do anything a client can do. In particular, it is 546 quite possible to establish a SIP session between two peers. 548 o It is possible to have a P2PSIP Overlay that consists of just 549 peers. However, it is NOT possible to have a P2PSIP Overlay that 550 consists of just clients, since a client can only connect to a 551 peer. 553 3.4. Example Signalling Message Flows 555 The following show very high level examples of message flows for 556 various interactions of devices within the reference model. In each 557 case, we DO NOT show the flow of messages exchanged between P2PSIP 558 peers to lookup information, since the exact nature of these flows 559 and even who the messages would flow between will be a function of 560 the particular data structure and protocol that is selected. We do 561 however indicate when the lookups occur. 563 As the working group makes various design decisions, the authors will 564 update this document with more details on the various message flows. 566 In a solution where the P2PSIP Client Protocol is some protocol other 567 than SIP, all of the following example flows are needed. In a design 568 where unmodified SIP is used for the P2PSIP Client, Section 569 Section 3.4.2 is not needed. 571 3.4.1. P2PSIP Peer contacts P2PSIP Peer 573 The following diagram shows P2PSIP UA Peer "E" placing a call to a 574 user which is currently using the SIP UA on peer "F". The steps in 575 this operation are: 577 1. UA Peer "E" first uses the P2PSIP Peer Protocol to communicate 578 among the peers and obtain the location of the user. As a result 579 of this operation, it is determined that the user is currently 580 using the SIP UA on peer "F". (The flow is not shown as this 581 will depend on the protocol designed). 583 2. "E" then establishes a session directly with "F" using a 584 conventional SIP INVITE/200 OK mechanism. 586 SIP INVITE/200 OK 587 /----------------\ 588 / \ --->PSTN 589 +------+ N +------+ +---------+ / 590 | | A | | | Gateway |-/ 591 | UA |####T#####| UA |#####| Peer |######## 592 | Peer | N | Peer | | G | # P2PSIP 593 | E | A | F | +---------+ # Client 594 | | T | | # Protocol 595 +------+ N +------+ # | 596 # A # | 597 NATNATNATNAT # | 598 # # | \__/ 599 NATNATNATNAT +-------+ v / \ 600 # N | |=====/ UA \ 601 +------+ A P2PSIP Overlay | | /Client\ 602 | | T | Peer | |___C__| 603 | UA | N Route Data | Q | 604 | Peer | A +-------+ 605 | D | T P2PSIP Peer Protocol # 606 | | N # 607 +------+ A # 608 # T # 609 # N +-------+ +-------+ # 610 # A | | | | # 611 #########T####| Proxy |########| Redir |####### 612 N | Peer | | Peer | 613 A | P | | R | 614 T +-------+ +-------+ 616 Figure: P2PSIP Peer to Peer 618 3.4.2. P2PSIP Client contacts P2PSIP Peer 620 NOTE: In a design where unmodified SIP is used for the P2PSIP Client 621 protocol, this case does not exist/is not needed. Sections 622 Section 3.4.3 and Section 3.4.4, covering conventional SIP access are 623 all that are required. 625 The following diagram shows P2PSIP UA Client "C" placing a call to a 626 user which is currently using the SIP UA on Peer "F". The steps are: 628 1. "C" first sends a request to peer "Q" for the location of the 629 user it wishes to contact. This request is sent using the P2PSIP 630 Client Protocol. 632 2. Some messages are exchanged among peer "Q" and other peers in the 633 overlay using the P2PSIP Peer Protocol to perform the lookup. 634 The details of this operation are not shown as this will depend 635 on the protocol designed. 637 3. Peer "Q" returns a response to Client "C" (using the P2PSIP 638 Client Protocol) saying that the user is currently using the SIP 639 UA on Peer "F". 641 4. "C" then establishes a session directly with "F" using a 642 conventional SIP INVITE/200 OK mechanism. 644 SIP INVITE/200 OK 645 /----------------------------------------+ 646 / | 647 / --->PSTN | 648 +------+ N +------+ +---------+ / | 649 | | A | | | Gateway |-/ | 650 | UA |####T#####| UA |#####| Peer |######## | 651 | Peer | N | Peer | | G | # P2PSIP | 652 | E | A | F | +---------+ # Client | 653 | | T | | # Protocol | 654 +------+ N +------+ # | | 655 # A # | | 656 NATNATNATNAT # | | 657 # # | \__/ | 658 NATNATNATNAT +-------+ v / \ | 659 # N | |=====/ UA \ / 660 +------+ A P2PSIP Overlay | | /Client\/ 661 | | T | Peer | |___C__| 662 | UA | N Route Data | Q | 663 | Peer | A +-------+ 664 | D | T P2PSIP Peer Protocol # 665 | | N # 666 +------+ A # 667 # T # 668 # N +-------+ +-------+ # 669 # A | | | | # 670 #########T####| Proxy |########| Redir |####### 671 N | Peer | | Peer | 672 A | P | | R | 673 T +-------+ +-------+ 675 Figure: P2PSIP Client to Peer 677 3.4.3. Conventional SIP Device using a Proxy Peer 679 The following diagram shows a conventional SIP device, SIP UA "A", 680 establishing a dialog with UA Peer "F". The steps in this example 681 are: 683 1. "A" sends a conventional SIP INVITE to Proxy Peer "P". 685 2. Proxy Peer "P" uses the P2PSIP Overlay Protocol to locate the 686 target. (The flow is not shown as this will depend on the 687 protocol designed), in this case UA Peer "F". 689 3. "P" forwards the SIP request to the destination and proxies the 690 response back to "A". 692 --->PSTN 693 +------+ N +------+ +---------+ / 694 | | A | | | Gateway |-/ 695 | UA |####T#####| UA |#####| Peer |######## 696 | Peer | N | Peer | | G | # P2PSIP 697 | E | A | F | +---------+ # Client 698 | | T | | # Protocol 699 +------+ N +------+ # | 700 # A | # | 701 NATNATNATNAT | # | 702 # | # | \__/ 703 NATNATNATNAT | +-------+ v / \ 704 # N | | |=====/ UA \ 705 +------+ A P2PSIP Overlay | | /Client\ 706 | | T | | Peer | |___C__| 707 | UA | N | | Q | 708 | Peer | A | +-------+ 709 | D | T | SIP INVITE/200 OK # 710 | | N | # 711 +------+ A | # 712 # T | # 713 # N +-------+ +-------+ # 714 # A | | | | # 715 #########T####| Proxy |########| Redir |####### 716 N | Peer | | Peer | 717 A | P | | R | 718 T +-------+ +-------+ 719 / 720 / 721 \__/ / SIP INVITE/200 OK 722 /\ / 723 / \/ 724 / UA \ 725 /______\ 726 SIP UA A 728 Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer 729 Proxy 731 3.4.4. Conventional SIP Device Using a Redirect Peer 733 The following diagram shows a second conventional SIP device, SIP UA 734 "A" establishing a dialog with a P2PSIP Client UA "C". 736 1. "A" sends a conventional SIP INVITE to the Redirect Peer "R". 738 2. Redirect Peer "R" uses the P2PSIP Peer Protocol to locate the 739 target, in this case P2PSIP Client UA "C". (The flow is not 740 shown as this will depend on the protocol designed). In contrast 741 to the Proxy peer example above, "R" returns the result of the 742 lookup to "A" as a 302 Moved message, with a contact of "C" (the 743 conventional SIP 302 mechanism), rather than proxying the request 744 for "A". 746 3. The conventional SIP UA "A" device can then establish the dialog 747 directly with UA Client "C", even though "A" has no awareness of 748 the P2PSIP Overlay, or of the P2PSIP Client Protocol. 750 --->PSTN 751 +------+ N +------+ +---------+ / 752 | | A | | | Gateway |-/ 753 | UA |####T#####| UA |#####| Peer |######## 754 | Peer | N | Peer | | G | # P2PSIP 755 | E | A | F | +---------+ # Client 756 | | T | | # Protocol 757 +------+ N +------+ # | 758 # A # | 759 NATNATNATNAT # | 760 # # | \__/ 761 NATNATNATNAT +-------+ v / \ 762 # N | |=====/ UA \ 763 +------+ A P2PSIP Overlay | | /Client\ 764 | | T | Peer | |___C__| 765 | UA | N Route Data | Q | | 766 | Peer | A +-------+ | 767 | D | T P2PSIP Peer Protocol # | 768 | | N # 3) SIP INVITE 769 +------+ A # /200 OK 770 # T # | 771 # N +-------+ +-------+ # | 772 # A | | | | # | 773 #########T####| Proxy |########| Redir |####### | 774 N | Peer | | Peer | / 775 A | P | | R | / 776 T +-------+ +-------+ / 777 \ / 778 \ / 779 1) SIP INVITE \ \__/ / 780 /302 Moved \ /\ / 781 \ / \ / 782 \/ UA \/ 783 /______\ 784 SIP UA A 786 Figure: Redirect from P2PSIP Overlay 788 3.5. Conceptual Outline of Operations 790 3.5.1. Enrolling and Inserting an P2PSIP Peer 792 Peers are the full-function "routing and storage" nodes of a P2PSIP 793 Overlay. When a new peer is first created, it must enroll in the 794 P2PSIP Overlay. We currently have no defined mechanism for this 795 (should this group define one?), but we know that once the process is 796 complete, the new peer will have at least a P2PSIP Peer-ID and 797 optionally a set of credentials. 799 After enrollment, each time the peer connects to the overlay, it must 800 insert itself. We don't have a defined protocol mechanism for this, 801 and assume we need one. Presumably the inserting peer connects with 802 a P2PSIP Bootstrap Peer (possibly with the aid of a P2PSIP Bootstrap 803 Server), presents its credentials, and after exchanging some messages 804 with other P2PSIP Peers, ends up connected to the overlay. It will 805 then have some knowledge of neighbors (successor, precursor, finger 806 tables, or whatever the distribution mechanism defines) and is able 807 to store data on behalf of and route requests to other nodes in the 808 P2PSIP overlay. 810 3.5.2. More on The Difference Between a Peer, Client, and User Agent 812 P2PSIP Peers directly interact with and contain the routing and 813 storage fabric of the overlay. P2PSIP Clients simply use the routing 814 and storage facilities provided by the peers to get and put 815 information. The peers speak the P2PSIP Peer Protocol, which can 816 express all the necessary routing and storage operations required for 817 the overlay. Clients speak the P2PSIP Client protocol, which is 818 presumably a subset of the peer protocol, and is limited to storage 819 insertion (put) and storage retrieval (get). Some designs do not 820 require a separate client protocol. 822 Some peers and some clients may be coupled to SIP user agents, making 823 them P2PSIP User Agents capable of both sending and receiving 824 conventional SIP messages (as per a SIP UA) using conventional SIP 825 resolution procedures and of using the resolution facilities provided 826 by the overlay. 828 The mix and configuration of peers, clients, and P2PSIP UAs is 829 expected to vary depending on the deployment scenario. For example, 830 an ad-hoc scenario might deploy nothing but P2PSIP Peers, each of 831 which is coupled to a P2PSIP User Agent, using a broadcast or 832 multicast bootstrap mechanism. Another common scenario, the "self 833 organizing proxy farm", might consist of P2PSIP Peers, each of which 834 is coupled to a SIP proxy/registrar function. 836 Some of the systems proposed that use SIP for the P2PSIP Client 837 protocol essentially remove that protocol from their design. 838 Standard SIP messages are sent to a proxy or redirect server which 839 speaks the P2PSIP Peer Protocol, eliminating the need for another 840 protocol. 842 3.5.3. Enrolling a User and Inserting a P2PSIP User Agent 844 P2PSIP Clients and Peers are the nodes of a P2PSIP Overlay. Users 845 are named entities that are associated with a Peer or Client. 847 To get started, users must be enrolled in the overlay. We do not 848 have a process or protocol for this, nor are we certain we need a 849 standardized mechanism. We presume that after enrollment, the user 850 has a distinguished name within the overlay (example: 851 sip:bob@example.com) and a set of credentials useful for 852 authenticating its usage of the distinguished name. One possible 853 mechanism for these credentials would be an x.509 certificate. It 854 might also be possible to use a PGP key, a password, or some other 855 mechanism. Presumably following enrollment, the user is also 856 equipped with the information needed to connect to the overlay, such 857 as the address of a bootstrap server. Whether this startup 858 information is delivered as a part of enrollment or through some 859 separate configuration process remains an open question, and it is 860 not clear it is within the scope of the proposed WG. 862 Once a user is enrolled, the user may exercise a P2PSIP User Agent to 863 insert into the P2PSIP Overlay. We currently have no protocol 864 mechanism for this, and need to define one. The P2PSIP UA exercises 865 the associated P2PSIP Peer or P2PSIP Client to execute the 866 "registration" function and insert a route for the user into the 867 P2PSIP overlay. This function is described as a "PUT" request, and 868 results in the storage of an authenticated route-set for the user in 869 the P2PSIP overlay, such that the terminus of the route is the URI of 870 the user at the P2PSIP UA. This is analogous to "registration" in a 871 classic SIP environment, and one mechanism proposed is in fact to use 872 the SIP REGISTER method. Presumably, the P2PSIP UA connects to a 873 peer or client and uses the user's credentials to authenticate a 874 route-set (Contact: plus Path:) to itself, and the peer or client 875 stores the route-set into the overlay, using a key derived from the 876 user's identity. 878 3.5.4. Bootstrapping 880 If a client or peer is just starting up and wants to join the 881 overlay, then it first needs to find a P2PSIP Bootstrap Peer. 882 Locating a P2PSIP Bootstrap Peer might be done in a number of ways: 884 o By remembering peers that were part of the overlay the last time 885 the node was part of the overlay; 887 o Through a multicast discovery mechanism (e.g., something similar 888 to the OSPF Hello protocol); 890 o Through manual configuration; or 892 o By contacting a P2PSIP Bootstrap Server, and using it to locate a 893 bootstrap peer. 895 A client or peer might reasonably try each of the methods (and 896 perhaps others) in some order or in parallel until it succeeds in 897 finding a bootstrap peer. 899 Like a bootstrap peer, there are many ways that a peer or client 900 could locate a P2PSIP Bootstrap Server. One likely method is for the 901 peer to do a DNS lookup on a well-known URL. 903 After discovering the address of a peer, the behavior of the starting 904 node will vary depending on whether it is intending to be a peer or a 905 client. If it is intending to be a peer, it goes into the P2PSIP 906 Peer Insertion process, at the conclusion of which it is actively 907 participating in the target overlay as a peer and is capable of 908 routing requests and storing records on behalf of the P2PSIP overlay. 909 If it is intending to be a client, it does not bother with insertion, 910 but merely contacts the discovered peer in order to use the overlay. 912 In the typical case, the peer or client coming up is also a P2PSIP 913 User Agent with one or more associated P2PSIP Resource (User) 914 Identifiers. The next step then is to insert a P2PSIP Resource 915 Record (a Contact:) into the P2PSIP Overlay. 917 Ideally, the mechanism for locating a bootstrap peer and handling a 918 new peer or client will attempt to distribute the load evenly across 919 the various nodes involved. 921 4. Questions 923 This section lists some of the open issues that the proposed P2PSIP 924 Working Group will have to address in the process of defining the 925 Peer and Client protocols. 927 4.1. PP2PSIP Peer Protocol 929 This may or may not be SIP. What should it be? Alternatives include 930 SIP, a full IETF protocol based on OpenDHT, or something else. Do we 931 need to define a new protocol? Will implementors want to implement a 932 new protocol? 934 4.2. P2PSIP Client Protocol 936 This may or may not be SIP. What should it be? It defines only GET/ 937 PUT operations, which could be done using SIP REGISTER transactions. 938 Essentially disappears if we do select SIP. 940 4.3. How Do We Find Gateways? 942 This needs to be not only netpath efficient, but also embodies 943 elements of the TRIP and SPEERMINT problems. 945 4.4. NAT Traversal 947 We assume that some or even many peers will be behind NATs. NATs 948 introduce two problems: a) how to learn the address and port that can 949 be used to reach the peer or client, and b) how to set up the 950 necessary permissions (or "filtering entries") in the NAT to allow 951 inbound packets. The IETF is currently defining the basic tools to 952 solve these problems, namely the STUN/TURN/ICE suite of protocols 953 [15] [14] [16] and the SIP-Outbound mechanism [17]. What the working 954 group needs to do is work out how to use these tools to allow 955 communication to peers behind NATs. In particular: 957 1. How to send P2PSIP Peer Protocol or P2PSIP Client Protocol 958 messages between two peers or clients which may be behind 959 different NATs? 961 2. How to send SIP messages between two peers or clients which may 962 be behind different NATs? 964 3. How to locate STUN servers and media relays, especially when 965 these may be services offered by peers or clients? 967 We presume that the question of how to send media between two peers 968 or clients is already solved by the STUN/TURN/ICE suite of protocols, 969 assuming that the necessary STUN servers and media relays can be 970 located. 972 4.5. Cryptotransparency 974 When forwarding requests, are the bodies of the requests visible to 975 peers? If so, this creates substantial security problems that the 976 deployers of conventional SIP have been willing to mostly ignore. 977 Can we make peers cryptotransparent (like HTTP proxies) when security 978 is requested? 980 4.6. Record Formats 982 Clearly we need user routing records stored into the P2PSIP overlay. 983 Do we need other sorts of record? If so, what? How do we 984 differentiate between or classify records? Do we end up with many 985 records per user per client, or do we aggregate the per-client or 986 per-user view using something like XML? 988 4.7. Peer and Client Enrollment Protocols 990 We know that we need to enroll peer and client nodes into a P2PSIP 991 Overlay. Do we define a protocol or process for this, assume it will 992 happen externally, or just provide an existence-proof argument? 994 4.8. Peer and User Credentials 996 We believe that some form of credential will be used for 997 authenticating peers and users in each P2PSIP Overlay. It remains to 998 be determined what the characteristics of the certificates will need 999 to be, and the use of self-signed vs. CA-produced certificates 1000 remains an open issue. 1002 4.9. Bootstrapping 1004 We know that sometimes peers or clients will start up without 1005 knowledge of how to find a peer for insertion. In this case, what is 1006 the mechanism that a new peer or client uses to find a P2PSIP 1007 Bootstrap peer? 1009 4.10. Credential Recovery 1011 One reader suggested that we extend the definition of P2PSIP Peer 1012 Enrollment to cover the case where a previously-inserted peer has 1013 lost its credentials (through, perhaps, being moved to a different 1014 host) and wishes to recover them without necessarily creating a new 1015 P2PSIP Peer-ID. The editors are inclined to believe that this is an 1016 operational issue, not a matter of definition, but would like to seek 1017 a broader consensus before concluding the topic. A similar question 1018 applies to user enrollment. 1020 4.11. Overlapping Domains 1022 If the P2PSIP Resource (User) Identifier is not scoped to a single 1023 DNS domain, this would appear to allow nodes from two or more 1024 apparent domains to share a single P2PSIP Overlay. What, if 1025 anything, do we need to say about this mode of operation? 1027 4.12. Hybrid Domains 1029 It appears possible to have some hosts within a domain using 1030 conventional SIP and some using P2PSIP. This potentially raises a 1031 number of questions: 1) What should happen if we want to run a P2PSIP 1032 overlay in an existing SIP domain? 2) Do the existing redir/proxy 1033 servers need to be coupled with a peer layer? 3) When would an 1034 overlay peer want to discover them as opposed to looking in the 1035 overlay? 4) Is better not to run conventional SIP with P2PSIP? 5) 1036 When conventional and P2PSIP are run together, shall the existing 1037 redir servers keep their local databases or switch to the overlay 1038 storage. 1040 A related question is whether a UA could use the same AOR in 1041 conventional SIP and in P2PSIP? 1043 4.13. Admissions Control 1045 What do we need to say about admissions control with respect to the 1046 enrollment of peers and users? Do we need to discuss per-call 1047 admissions control in a P2P environment? 1049 4.14. Users versus Resources 1051 This model presumes that all addressable elements, aka "users", are 1052 unique. Are their other classes of resources that need some sort of 1053 class-addressable identifier that does not refer to a unique user? 1055 5. Security Considerations 1057 Building a P2PSIP system has many security considerations, many of 1058 which we have only begun to consider. We anticipate that the 1059 protocol documents describing the actual protocols will deal more 1060 thoroughly with security topics. 1062 6. IANA Considerations 1064 This document presently raises no IANA considerations. 1066 7. Acknowledgements 1068 This document draws heavily from the contributions of many 1069 participants in the P2PSIP Mailing List but the authors are 1070 especially grateful for the support of Spencer Dawkins, Cullen 1071 Jennings, and Henning Schulzrinne, all of whom spent time on phone 1072 calls about this document or provided text. Additionally, Spencer 1073 provided a large portion of the ASCII art contained in this document. 1075 8. References 1077 8.1. Normative References 1079 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1080 Levels", BCP 14, RFC 2119, March 1997. 1082 [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1083 Resource Locators (URL)", RFC 1738, December 1994. 1085 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1086 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1087 Session Initiation Protocol", RFC 3261, June 2002. 1089 [4] Mockapetris, P., "Domain names - concepts and facilities", 1090 STD 13, RFC 1034, November 1987. 1092 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1093 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1095 [6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1096 Extension Header Field for Registering Non-Adjacent Contacts", 1097 RFC 3327, December 2002. 1099 8.2. Informative References 1101 [7] Bryan, D., "A P2P Approach to SIP Registration and Resource 1102 Location", draft-bryan-sipping-p2p-02 (work in progress), 1103 March 2006. 1105 [8] Shim, E., "An Architecture for Peer-to-Peer Session Initiation 1106 Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in 1107 progress), March 2006. 1109 [9] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet 1110 Communications", draft-johnston-sipping-p2p-ipcom-02 (work in 1111 progress), March 2006. 1113 [10] Matthews, P., "Industrial-Strength P2P SIP", 1114 draft-matthews-sipping-p2p-industrial-strength-00 (work in 1115 progress), February 2005. 1117 [11] Risson, J. and T. Moors, "Survey of Research towards Robust 1118 Peer-to-Peer Networks: Search Methods", 1119 draft-irtf-p2prg-survey-search-00 (work in progress), 1120 March 2006. 1122 [12] Bryan, D., "Use Cases for Peer-to-Peer Session Initiation 1123 Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 (work 1124 in progress), December 2005. 1126 [13] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1127 June 2005. 1129 [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 1130 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 1131 progress), October 2006. 1133 [15] Rosenberg, J., "Simple Traversal Underneath Network Address 1134 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 1135 (work in progress), July 2006. 1137 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1138 Methodology for Network Address Translator (NAT) Traversal for 1139 Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in 1140 progress), October 2006. 1142 [17] Jennings, C. and R. Mahy, "Managing Client Initiated 1143 Connections in the Session Initiation Protocol (SIP)", 1144 draft-ietf-sip-outbound-04 (work in progress), June 2006. 1146 URIs 1148 [18] 1150 Authors' Addresses 1152 David A. Bryan 1153 SIPeerior Technologies and College of William and Mary 1154 3000 Easter Circle 1155 Williamsburg, Virginia 23188 1156 USA 1158 Phone: unlisted 1159 Email: bryan@ethernot.org 1160 Philip Matthews 1161 Avaya 1162 100 Innovation Drive 1163 Ottawa, Ontario K2K 3G7 1164 Canada 1166 Phone: +1 613 592 4343 x224 1167 Email: philip_matthews@magma.ca 1169 Eunsoo Shim 1170 Panasonic Digital Networking Lab 1171 Two Research Way, 3rd Floor 1172 Princeton, New Jersey 08540 1173 USA 1175 Phone: unlisted 1176 Email: eunsoo@research.panasonic.com 1178 Dean Willis 1179 Cisco Systems 1180 3100 Independence Pkwy #311-164 1181 Plano, Texas 75075 1182 USA 1184 Phone: unlisted 1185 Email: dean.willis@softarmor.com 1187 Full Copyright Statement 1189 Copyright (C) The Internet Society (2006). 1191 This document is subject to the rights, licenses and restrictions 1192 contained in BCP 78, and except as set forth therein, the authors 1193 retain all their rights. 1195 This document and the information contained herein are provided on an 1196 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1197 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1198 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1199 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1200 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1201 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1203 Intellectual Property 1205 The IETF takes no position regarding the validity or scope of any 1206 Intellectual Property Rights or other rights that might be claimed to 1207 pertain to the implementation or use of the technology described in 1208 this document or the extent to which any license under such rights 1209 might or might not be available; nor does it represent that it has 1210 made any independent effort to identify any such rights. Information 1211 on the procedures with respect to rights in RFC documents can be 1212 found in BCP 78 and BCP 79. 1214 Copies of IPR disclosures made to the IETF Secretariat and any 1215 assurances of licenses to be made available, or the result of an 1216 attempt made to obtain a general license or permission for the use of 1217 such proprietary rights by implementers or users of this 1218 specification can be obtained from the IETF on-line IPR repository at 1219 http://www.ietf.org/ipr. 1221 The IETF invites any interested party to bring to its attention any 1222 copyrights, patents or patent applications, or other proprietary 1223 rights that may cover technology that may be required to implement 1224 this standard. Please address the information to the IETF at 1225 ietf-ipr@ietf.org. 1227 Acknowledgment 1229 Funding for the RFC Editor function is provided by the IETF 1230 Administrative Support Activity (IASA).