idnits 2.17.1 draft-bryan-p2psip-app-scenarios-00.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, updated by RFC 4748 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 832. 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 IETF Trust Copyright Line does not match the current year == Line 749 has weird spacing: '... at the netwo...' == Line 753 has weird spacing: '...etworks the p...' == Line 754 has weird spacing: '...tion of a des...' -- 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 (November 7, 2007) is 6008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP D. Bryan 3 Internet-Draft SIPeerior Technologies, Inc. 4 Intended status: Informational E. Shim 5 Expires: May 10, 2008 Locus Telecom 6 B. Lowekamp 7 SIPeerior; William & Mary 8 S. Dawkins, Ed. 9 Huawei (USA) 10 November 7, 2007 12 Application Scenarios for Peer-to-Peer Session Initiation Protocol 13 (P2PSIP) 14 draft-bryan-p2psip-app-scenarios-00 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 May 10, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document attempts to identify and classify application scenarios 48 of P2P based SIP. It does not attempt to exhaustively enumerate 49 these scenarios, and is focused exclusively on scenarios related to 50 real-time IP communication. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Application Scenario Attributes . . . . . . . . . . . . . . . 4 57 4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Global Internet Environment . . . . . . . . . . . . . . . 6 59 4.1.1. Public P2P VoIP Service Providers . . . . . . . . . . 6 60 4.1.2. Open Global P2P VoIP Network . . . . . . . . . . . . . 7 61 4.1.3. Wide Area Networks of Consumer Electronics Devices . . 7 62 4.1.4. Multimedia content sharing via Application Layer 63 Multicasting (Content Providers or Ad Hoc) . . . . . . 8 64 4.2. Environments with Limited Connectivity to the Internet 65 or Infrastructure . . . . . . . . . . . . . . . . . . . . 10 66 4.2.1. Ad-Hoc and Ephemeral Groups . . . . . . . . . . . . . 11 67 4.2.2. Extending the Reach of Mobile Devices . . . . . . . . 11 68 4.2.3. Impeded Access . . . . . . . . . . . . . . . . . . . . 12 69 4.2.4. Local Area Networks of Consumer Electronics Devices . 12 70 4.3. Managed, Private Network Environments . . . . . . . . . . 12 71 4.3.1. Serverless or Small Scale IP-PBX . . . . . . . . . . . 14 72 4.3.2. P2P for Redundant SIP Proxies . . . . . . . . . . . . 14 73 4.3.3. Failover for Centralized Systems . . . . . . . . . . . 14 74 5. Changes from draft-bryan-p2psip-usecases-00 . . . . . . . . . 15 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Intellectual Property and Copyright Statements . . . . . . . . . . 19 85 1. Introduction 87 This document attempts to identify and classify application scenarios 88 for Peer-to-Peer (P2P) based Session Initiation Protocol (SIP) 89 [RFC3261]. Identifying application scenarios will help to understand 90 and clarify requirements of P2PSIP. In particular, these application 91 scenarios will assist the P2PSIP community in identifying 92 commonalities and differences between requirements for different 93 application scenarios, which in turn will help define the near-term 94 scope of specifications and provide a perspective on future 95 specifications. 97 Only application scenarios related to real-time IP communications, 98 such as VoIP, Instant Messaging (IM), and presence are considered in 99 this document. Application scenarios of other kinds, even if 100 interesting and possibly useful applications of P2PSIP, are out of 101 scope for this document. Thus, application scenarios described 102 herein are application scenarios of P2P IP real-time communications, 103 and P2PSIP is a protocol choice rather than a constraining factor for 104 most of them. In describing application scenarios, no deliberation 105 on implementation is provided. Some of the application scenarios 106 presented may already be implemented or deployed, possibly using 107 proprietary technology. 109 The list of application scenarios compiled here is by no means a 110 complete list of uses cases of P2PSIP, and further cases would be 111 limited only by the imagination. P2PSIP participants who expect to 112 use P2PSIP technology for application scenarios that don't match any 113 of the combinations of attributes included in this document are 114 invited to contribute descriptions of additional application 115 scenarios to the P2PSIP working group mailing list. 117 We tried to capture the deployment characteristics of the application 118 scenarios such as whether the nodes will span over multiple physical 119 network administrative domains or whether the ID must be controlled 120 by a central authority. The characteristics are presented as 121 scenario-attribute tables. The values in the tables are what we 122 think are most likely and we understand there may be similar 123 scenarios with different choices for some attribute values. 125 Some of these application scenarios, while difficult to implement 126 using a traditional client server SIP (CS SIP) architecture may not 127 require P2P and could be implemented in other ways. While these have 128 often been presented as scenarios calling for P2P communication, the 129 authors recognize that other technologies may also be applicable to 130 these application scenarios. 132 Since the original iteration of this document, the P2PSIP WG has been 133 formed and numerous documents have been submitted that include some 134 number of application scenarios. We will not try to enumerate them 135 here. This draft draws from these documents, as well as discussions 136 at the P2PSIP ad-hoc and WG meetings and numerous mailing list and 137 personal conversations of the authors. 139 2. Terminology 141 We use terminology defined in RFC 3261 [RFC3261] in this document 142 without further definition. 144 We use terminology defined in Concepts and Terminology for Peer to 145 Peer SIP [I-D.willis-p2psip-concepts] draft in this document without 146 further definition. 148 We define the attributes used in the discussion of each application 149 scenario in Section 3. 151 3. Application Scenario Attributes 153 The attributes used in the application scenarios matrixes in 154 subsequent sections are explained here. 156 Application Scenario: The name of an application scenario 157 (previously called a "use case"). 158 Section in Draft: A cross-reference to the section number in this 159 draft where the application scenario is described. 160 Number of Peers: The number of peers that will be active in an 161 overlay at any given point in time. 162 Number of Users: The number of users that will be served by an 163 overlay at any given point in time. 164 Note that if there are more users than peers, this implies that 165 some client protocol is required, whether "client protocol" is 166 a P2PSIP client protocol or the SIP protocol (if the P2PSIP 167 overlay is also providing RFC 3263 [RFC3263]-style routing for 168 unmodified SIP clients). 169 Overlay spans administrative domains: Whether the overlay spans 170 across multiple physical network administrative domains. If 171 "yes", this makes IP multicast and centralized operations and 172 management unlikely. 173 Multicast Available: Whether "application-level multicast", "IP 174 multicast", or "link multicast" may be available for a typical 175 overlay. 177 Note that these are ordered - link multicast implies IP 178 multicast could be available, and IP multicast implies 179 application-level multicast could be available. 180 P2P Client Support: Whether the overlay need to support a P2P Client 181 protocol, i.e., whether the overlay contains P2P Clients as 182 well as Peers. 183 Interoperation with CS-SIP: Whether the overlay must also interact 184 with legacy SIP clients and SIP proxies. 185 Note that one or more peers in the overlay may also act as PSTN 186 gateways. 187 Non-stop Operation: Whether this application scenarios allows the 188 overlay to become unavailable for periods of time (for example, 189 could an overlay stop operating in order to change DHT 190 algorithms, or would the overlay have to support two DHT 191 algorithms in "ships in the night" mode?) 192 Centralized Operations and Management: Whether any centralized 193 operations/management entity is responsible for successful 194 operation of the overlay. 195 Centralized ID Control: Whether ID assignment by central authority 196 is required within an overlay (basically, whether the overlay 197 can be Sybil-attacked - the theory is that if IDs are 198 controlled by a centralized entity, overlay operators simply 199 remove misbehaving users from the authorization registry). 200 Supports Anonymous Users: Whether this application scenario allows 201 users to connect to an overlay without providing any identity. 202 Carrier-Class Robustness: Whether the overlay must provide reliable 203 storage and retrieval in the face of node failure. 204 NATs within a single overlay Whether the peer protocol must expect 205 to perform NAT traversal as part of normal operation. 206 DNS available: Whether DNS is available so that peers may perform 207 DNS lookups as part of the overlay JOIN operation. 208 End-to-end SIP Encryption: Whether this application scenario 209 requires SIP traffic between two peers to be encrypted, so SIP 210 requests and responses are not visible to intermediate peers 211 (peers that forward traffic between two peers that aren't 212 directly connected). In these cases, hop-by-hop TLS 213 encryption, although appropriate when traversing trusted SIP 214 Proxies, is not appropriate when traversing untrusted P2PSIP 215 Peers. 217 4. Application Scenarios 219 Application scenarios are grouped according to the characteristics of 220 the network environment in which the end users or devices 221 participating in the P2P overlay are communicating with each other. 223 4.1. Global Internet Environment 225 The global Internet environment consists of a large number of 226 autonomous networks with diverse characteristics. Thus, there is no 227 central administration or network control of the physical network on 228 a global scale. Communication paths between two remote devices may 229 span multiple administrative domains and should be assumed to be 230 insecure. Note that most well-known P2P file sharing overlay 231 networks have operated in this environment. 233 4.1.1. Public P2P VoIP Service Providers 235 Skype is an outstanding example of a public VoIP service provider 236 using P2P technology among end user devices, although Skype uses a 237 proprietary protocol. Recent research has shown [skypestudy] that 238 Skype uses a central login server, responsible for management of 239 registered user names. End users are authenticated via a certificate 240 signed by a central server. End user devices are distributed across 241 the global Internet. The number of participating end user devices is 242 very large. A major motivation of using P2P between end user devices 243 for a commercial VoIP service is a reduction in infrastructure and 244 operational costs. 246 Table 1 provides a high-level overview of this category. 248 +------------------------+----------------------+-------------------+ 249 | Application Scenario | Public P2P VoIP | Open Global P2P | 250 | | Service Providers | VoIP Network | 251 +------------------------+----------------------+-------------------+ 252 | Section in Draft | 4.1.1 | 4.1.2 | 253 | Number of Peers | hundreds | thousands | 254 | Number of Users | millions | millions | 255 | Overlay spans | no | yes | 256 | administrative domains | | | 257 | Multicast Available | no | no | 258 | P2P Client Support | yes | yes | 259 | Interaction with | yes | yes | 260 | CS-SIP | | | 261 | Non-stop Operation | yes | yes | 262 | Centralized Operations | yes | yes | 263 | and Management | | | 264 | Centralized ID Control | yes | no | 265 | Supports Anonymous | no | no | 266 | Users | | | 267 | Carrier-Class | yes | yes | 268 | Robustness | | | 269 | NATs within a single | yes | yes | 270 | overlay | | | 271 | DNS available | yes | yes | 272 | End-to-end SIP | yes | yes | 273 | Encryption | | | 274 +------------------------+----------------------+-------------------+ 276 Public P2P VoIP Service Providers and Open Global P2P VoIP Network 278 Table 1 280 4.1.2. Open Global P2P VoIP Network 282 This is a global P2P VoIP network in which there is no central 283 authority such as a single service provider. Anyone can join and 284 leave the network freely and anyone can implement the software to 285 participate in the overlay network. In such a system, the protocols 286 used must be based on open standards. This P2P VoIP network 287 resembles the global Internet itself in that it has distributed 288 management and growth, enables anyone to reach anyone else in the 289 overlay network, and any device supporting the standard protocols can 290 be used. 292 Table 1 provides a high-level overview of this category. 294 4.1.3. Wide Area Networks of Consumer Electronics Devices 296 Instant messaging application software provides presence, text and 297 media messaging, and file transfer capabilities between online users. 298 As more and more multimedia consumer electronics devices such as 299 cameras, camcorders and televisions become network aware, instant 300 sharing of multimedia content such as photos and video clips between 301 family members and friends will be desirable. VoIP may not be needed 302 on some of these consumer electronics devices, however in other cases 303 such as gaming, voice communication between users may be highly 304 desirable. As consumer electronics providers may desire to provide 305 these capabilities without investing in extensive server 306 capabilities, a global P2P network supporting presence is an 307 important infrastructure component for this application scenario. 309 Table 2 provides a high-level overview of this category. 311 +-----------------------------+-------------------------------------+ 312 | Application Scenario | Wide Area Networks of Consumer | 313 | | Electronics Devices | 314 +-----------------------------+-------------------------------------+ 315 | Section in Draft | 4.1.3 | 316 | Number of Peers | thousands | 317 | Number of Users | millions | 318 | Overlay spans | yes | 319 | administrative domains | | 320 | Multicast Available | no | 321 | P2P Client Support | yes | 322 | Interaction with CS-SIP | no | 323 | Non-stop Operation | no | 324 | Centralized Operations and | maybe | 325 | Management | | 326 | Centralized ID Control | maybe | 327 | Supports Anonymous Users | no | 328 | Carrier-Class Robustness | no | 329 | NATs within a single | yes | 330 | overlay | | 331 | DNS available | yes | 332 | End-to-end SIP Encryption | no | 333 +-----------------------------+-------------------------------------+ 335 Wide Area Networks of Consumer Electronics Devices 337 Table 2 339 4.1.4. Multimedia content sharing via Application Layer Multicasting 340 (Content Providers or Ad Hoc) 342 IP-layer multicasting is not generally available beyond the boundary 343 of single IP subnet. Application layer multicasting has become a 344 plausible alternative to IP-layer multicasting. In application layer 345 multicasting, the nodes that need to receive the content from the 346 same source form a distribution network, typically of a tree-like 347 topology, and relay the received content to other nodes in the 348 distribution network. This technique can be used to multicasting 349 video or audio stream to a number of nodes distributed over the 350 Internet (or across multiple IP subnets). 352 Note that this application scenario covers two types of deployments - 353 large-scale commercial audio or video distribution/broadcasting 354 services such as Internet radio or TV services ("Content Provider") 355 or to ad-hoc video sharing among a group of friends ("Ad Hoc"). 357 Table 3 provides a high-level overview of this category. 359 +----------------+--------------------------+-----------------------+ 360 | Application | Multimedia content | Multimedia content | 361 | Scenario | sharing via Application | sharing via | 362 | | Layer Multicasting | Application Layer | 363 | | (Content Providers) | Multicasting (Ad Hoc) | 364 +----------------+--------------------------+-----------------------+ 365 | Section in | 4.1.4 | 4.1.4 | 366 | Draft | | | 367 | Number of | hundreds | hundreds | 368 | Peers | | | 369 | Number of | thousands | thousands | 370 | Users | | | 371 | Overlay spans | yes | yes | 372 | administrative | | | 373 | domains | | | 374 | Multicast | application multicast | application multicast | 375 | Available | | | 376 | P2P Client | yes | yes | 377 | Support | | | 378 | Interaction | no | no | 379 | with CS-SIP | | | 380 | Non-stop | yes | no | 381 | Operation | | | 382 | Centralized | yes | no | 383 | Operations and | | | 384 | Management | | | 385 | Centralized ID | yes | no | 386 | Control | | | 387 | Supports | no | no | 388 | Anonymous | | | 389 | Users | | | 390 | Carrier-Class | yes | no | 391 | Robustness | | | 392 | NATs within a | yes | yes | 393 | single overlay | | | 394 | DNS available | yes | yes | 395 | End-to-end SIP | yes | no | 396 | Encryption | | | 397 +----------------+--------------------------+-----------------------+ 399 Multimedia content sharing via Application Layer Multicasting 400 (Content Provider and Ad Hoc) 402 Table 3 404 4.2. Environments with Limited Connectivity to the Internet or 405 Infrastructure 407 When there is no physical network available for stable deployment of 408 client server SIP or an instant deployment of real-time communication 409 systems is required, the P2P approach may be the only feasible 410 solution. Examples of such environment are isolated wireless ad-hoc 411 networks with no connection to the Internet or ad-hoc networks with 412 limited connectivity to the Internet in situations like outdoor 413 public events, emergencies, and battlefields. Any type of manual 414 configuration is difficult to achieve because technical support is 415 not readily available in such environment. In some cases, 416 connectivity to the global Internet may be available, but be very 417 expensive, of limited capacity, or unstable, such as satellite 418 connections. In such cases, it is preferable to localize 419 communications as much as possible, reducing dependency on any 420 infrastructure in the global Internet. 422 Table 4 provides a high-level overview of this category. 424 +----------------+-----------+-----------+----------+---------------+ 425 | Application | Ad-Hoc | Extending | Impeded | Local Area | 426 | Scenario | and | the Reach | Access | Networks of | 427 | | Ephemeral | of Mobile | | Consumer | 428 | | Groups | Devices | | Electronics | 429 | | | | | Devices | 430 +----------------+-----------+-----------+----------+---------------+ 431 | Section in | 4.2.1 | 4.2.2 | 4.2.3 | 4.2.4 | 432 | Draft | | | | | 433 | Number of | tens | hundreds | hundreds | tens | 434 | Peers | | | | | 435 | Number of | tens | hundreds | hundreds | tens | 436 | Users | | | | | 437 | Spans | no | no | yes | no | 438 | administrative | | | | | 439 | domains | | | | | 440 | Multicast | link | link | no | link | 441 | Available | multicast | multicast | | multicast | 442 | P2P Client | no | no | no | no | 443 | Support | | | | | 444 | Interaction | no | no | no | no | 445 | with CS-SIP | | | | | 446 | Non-stop | no | no | no | no | 447 | Operation | | | | | 448 | Centralized | no | no | no | no | 449 | Operations and | | | | | 450 | Management | | | | | 451 | Centralized ID | no | no | no | no | 452 | Control | | | | | 453 | Supports | yes | yes | yes | yes | 454 | Anonymous | | | | | 455 | Users | | | | | 456 | Carrier-Class | no | no | no | no | 457 | Robustness | | | | | 458 | NATs within a | no | no | yes | no | 459 | single overlay | | | | | 460 | DNS available | no | no | yes | yes | 461 | End-to-end SIP | no | no | yes | no | 462 | Encryption | | | | | 463 +----------------+-----------+-----------+----------+---------------+ 465 Environments with Limited Connectivity to the Internet or 466 Infrastructure 468 Table 4 470 4.2.1. Ad-Hoc and Ephemeral Groups 472 Groups of individuals meeting together have need for collaborative 473 communications systems that are ephemeral in nature, have minimum 474 (ideally zero) configuration, and do not depend on connectivity to 475 the Internet. These scenarios require an arbitrary number of users 476 to connect communications devices. These can include cases where 477 Internet connectivity due to remote location, inability to pay for 478 connectivity, or following a natural disaster where service is 479 interrupted. 481 Example: A group gets together for a meeting, but there is no 482 Internet connectivity. If the users establish a wireless ad hoc 483 network or have a base station, all users may connect and establish 484 chat sessions using an IM protocol with no need for server 485 configuration. 487 Example: Following a disaster, the local fire department arrives. 488 Each fire fighter has a wireless handset, and one or more trucks have 489 wireless base stations. When a nearby locality sends additional 490 rescuers, their wireless handsets should be able to instantly join 491 the communications network and communicate, without the need for 492 central configuration. 494 4.2.2. Extending the Reach of Mobile Devices 496 [anchor9] 498 A network of mobile devices can relay traffic between themselves to 499 reach a base station, even if the base station is out of reach of 500 that device. 502 Example: A user has a handset for communication that cannot reach a 503 base station. Some other user is within range of both that user and 504 a base station. This intermediate user can serve as a relay for the 505 caller who is out of range. A system might make this feature 506 optional for standard communication and mandatory for E911. 508 4.2.3. Impeded Access 510 Certain groups may have their ability to communicate impeded. These 511 users should be able to communicate without the need to connect to 512 any centralized servers, which may be blocked by providers upstream 513 of the user. A fully decentralized system cannot be completely 514 disconnected without removing connectivity at the basic Internet 515 level. 517 Example: A user wishes to use an IP telephony service to communicate 518 PC to PC with a friend, but the ports commonly used by these 519 services, or the servers used for authentication, are blocked by the 520 ISP because the ISP also offers communications systems and have a 521 vested interest in denying access to external communications systems. 523 Example: A user with an Internet enabled PDA devices wishes to 524 connect with colleagues, but traditional services are blocked to 525 ensure that SMS or voice minutes are used (at additional cost) 526 instead. 528 4.2.4. Local Area Networks of Consumer Electronics Devices 530 In addition to consumer devices sharing information with other users 531 across the Internet, having devices that can locate each other and 532 exchange information within the local LAN of a particular user may 533 also be an attractive application. In this case, devices could use 534 P2PSIP to locate multimedia resources available on other devices and 535 stream the information between the devices. 537 Example: A user wishes to share content among consumer electronics 538 devices within a home network. 540 4.3. Managed, Private Network Environments 542 A corporate network or a school campus network is an example of the 543 managed, private network environment. Most likely client server SIP 544 can be used and managed for real-time communication applications in 545 these environments. However, in certain scenarios, P2PSIP may be 546 used instead or as a complementary means, to achieve various goals 547 such as cost and management overhead reduction, scalability, and 548 system robustness. 550 Table 5 provides a high-level overview of this category. 552 +------------------+---------------+---------------+----------------+ 553 | Application | Serverless or | P2P for | Failover for | 554 | Scenario | Small Scale | Redundant SIP | Centralized | 555 | | IP-PBX | Servers | Systems | 556 +------------------+---------------+---------------+----------------+ 557 | Section in Draft | 4.3.1 | 4.3.2 | 4.3.3 | 558 | Number of Peers | hundreds | hundreds | tens | 559 | Number of Users | hundreds | hundreds | tens | 560 | Spans | no | no | no | 561 | administrative | | | | 562 | domains | | | | 563 | Multicast | IP multicast | IP multicast | IP multicast | 564 | Available | | | | 565 | P2P Client | no | no | no | 566 | Support | | | | 567 | Interaction with | yes | no | yes | 568 | CS-SIP | | | | 569 | Non-stop | yes | yes | yes | 570 | Operation | | | | 571 | Centralized | maybe | yes | yes | 572 | Operations and | | | | 573 | Management | | | | 574 | Centralized ID | self-cert? | yes | yes | 575 | Control | | | | 576 | Supports | no | no | no | 577 | Anonymous Users | | | | 578 | Carrier-Class | no | yes | yes | 579 | Robustness | | | | 580 | NATs within a | yes | no | no | 581 | single overlay | | | | 582 | DNS available | no | yes | yes | 583 | End-to-end SIP | no | no | no | 584 | Encryption | | | | 585 +------------------+---------------+---------------+----------------+ 587 Managed, Private Network Environments 589 Table 5 591 4.3.1. Serverless or Small Scale IP-PBX 593 Many small enterprises have a need for integrated communications 594 systems. These systems have slightly different requirements than 595 more traditional IP PBXs. For small enterprises, there may be no 596 administrator for these systems, requiring the systems to be 597 essentially self-configuring and/or self-organizing. Additional 598 endpoints should be able to be added with no requirements for 599 configuration on central devices. 601 These systems should offer the feature sets similar to those of 602 client server type PBX systems. Connectivity to the PSTN is an 603 important feature for these systems. In addition, they may support 604 features such as call transfer, voice mail, and possibly even other 605 communications modes such as instant messaging or media features such 606 as video or conference services. There are already commercial 607 products of this type. 609 Example: Small organizations without centralized IT 611 4.3.2. P2P for Redundant SIP Proxies 613 Service providers may wish to connect a farm of proxies together in a 614 transparent way, passing resources (user registrations or other call 615 information) between themselves with as little configuration or 616 traffic as possible. Ideally, the redundancy and exchange of 617 information should require a minimum of configuration between the 618 devices. P2P architecture between the proxies allows proxy farms to 619 be organized and operated in this way. With this approach, it is 620 easy to add more proxies with minimal service disruptions and 621 increases the robustness of the system. 623 Example: a SIP service provider may wish to scale SIP proxies by 624 using a P2PSIP overlay that provides RFC 3263 [RFC3263] request 625 routing services, instead of using either front-end load balancing 626 devices or making the structure of the proxy farm visible outside the 627 proxy farm itself. 629 4.3.3. Failover for Centralized Systems 631 A traditional centralized SIP server, such as used in an IP-PBX, 632 forms a single point of failure of an otherwise fault-independent 633 network. Relying on P2PSIP as a backup to the centralized server 634 allows the communications system to continue functioning normally in 635 the event of planned or unplanned service interruptions of the 636 central IP-PBX. When combined with a low-configuration P2PSIP PBX, 637 this can provide a simple, standalone communications system for the 638 developing world that allows local communication even when Internet 639 connectivity is severed. 641 Example: A small company has a central IP-PBX. When that device 642 experiences a failure, the handsets are able to transparently 643 continue operation for the 24 hours it takes to obtain a replacement 644 switch. 646 Example: A village in the developing world has connectivity that is 647 limited by weather (microwave connection) or is solar powered. It 648 would be desirable for intra-village communication to continue to 649 function in the absence of Internet connectivity. 651 5. Changes from draft-bryan-p2psip-usecases-00 653 This draft builds on the analysis done for an earlier draft, 654 draft-bryan-p2psip-usecases-00, now expired. For ease of reference, 655 Table 6 shows the mapping of use cases described in 656 draft-bryan-p2psip-usecases-00 onto the application scenarios 657 described in this document. 659 +---------------------------+--------------+------------------------+ 660 | Use Case | Section in | Application Scenario | 661 | | Use Cases | | 662 | | Draft | | 663 +---------------------------+--------------+------------------------+ 664 | Public P2P VoIP Service | 3.1.1 | (no change) | 665 | Providers | | | 666 | Open Global P2P VoIP | 3.1.2 | (no change) | 667 | Network | | | 668 | Presence Using Multimedia | 3.1.3 | Split into (Content | 669 | Consumer Electronics | | Provider) and (Ad Hoc) | 670 | Devices | | scenarios | 671 | Multimedia content | 3.1.4 | (no change) | 672 | sharing via Application | | | 673 | Layer Multicasting | | | 674 | Impeded Access | 3.2.1 | (no change) | 675 | Anonymous Communications | 3.2.2 | Became an attribute of | 676 | | | other scenarios | 677 | Security Conscious Small | 3.2.3 | Became an attribute of | 678 | Organizations | | other scenarios | 679 | Ad-Hoc and Ephemeral | 3.3.1 | (no change) | 680 | Groups | | | 681 | Emergency First Responder | 3.3.2 | Merged with Ad-Hoc and | 682 | Networks | | Ephemeral Groups | 683 | Extending the Reach of | 3.3.3 | (no change) | 684 | Mobile Devices | | | 685 | Deployments in the | 3.3.4 | Merged with Failover | 686 | Developing World | | | 687 | Serverless or Small Scale | 3.4.1 | (no change) | 688 | IP-PBX | | | 689 | P2P for Redundant SIP | 3.4.2 | (no change) | 690 | Servers | | | 691 | Failover for Centralized | 3.4.3 | (no change) | 692 | Systems | | | 693 +---------------------------+--------------+------------------------+ 695 Changes from draft-bryan-p2psip-usecases-00 697 Table 6 699 6. Acknowledgments 701 The following persons have contributed application scenarios or ideas 702 to this document: 704 Cullen Jennings, Philip Matthews, Henry Sinnreich, Adam Roach, Robert 705 Sparks, Kundan Singh, Henning Schulzrinne, K. Kishore Dhara, and 706 Salman A. Baset. 708 7. Security Considerations 710 The security requirements of the various application scenarios vary 711 tremendously. They should be discussed in more detail in this 712 document. 714 8. IANA Considerations 716 This document has no IANA Considerations. 718 9. References 720 9.1. Normative References 722 [I-D.willis-p2psip-concepts] 723 Willis, D., "Concepts and Terminology for Peer to Peer 724 SIP", draft-willis-p2psip-concepts-04 (work in progress), 725 March 2007. 727 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 728 A., Peterson, J., Sparks, R., Handley, M., and E. 730 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 731 June 2002. 733 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 734 Protocol (SIP): Locating SIP Servers", RFC 3263, 735 June 2002. 737 9.2. Informative References 739 [skypestudy] 740 Baset, S. and H. Schulzrinne, "An Analysis of the Skype 741 Peer-to-Peer Internet Telephony Protocol", Technical 742 Report, Department of Computer Science, Columbia 743 University 0309-04, September 2004. 745 Editorial Comments 747 [anchor9] Spencer has misgivings about "Extending the Reach of 748 Mobile Devices", based on (1) relaying at the link layer 749 or at the network layer would make more sense, and would 750 work for devices that do not support P2PSIP, and (2) 751 although small networks might work well enough when peers 752 simply forward a request "around the overlay", in larger 753 networks the problem space morphs from forwarding traffic 754 in *the* direction of a destination to routing traffic in 755 the *best* direction to the destination - a much harder 756 problem. 758 Authors' Addresses 760 David A. Bryan 761 SIPeerior Technologies, Inc. 762 3000 Easter Circle 763 Williamsburg, VA 23188 764 USA 766 Phone: +1 757 565 0101 767 Email: dbryan@sipeerior.com 768 Eunsoo Shim 769 Locus Telecommunications, Inc. 770 2200 Fletcher Ave. 6th FL 771 Fort Lee, NJ 07024 772 USA 774 Email: eunsoo@locus.net 776 Bruce B. Lowekamp 777 SIPeerior; William & Mary 778 3000 Easter Circle 779 Williamsburg, VA 23188 780 USA 782 Phone: +1 757 565 0101 783 Email: lowekamp@sipeerior.com 785 Spencer Dawkins (editor) 786 Huawei Technologies (USA) 787 1547 Rivercrest Blvd. 788 Allen, TX 75002 789 USA 791 Phone: +1 214 755 3870 792 Email: spencer@mcsr-labs.org 794 Full Copyright Statement 796 Copyright (C) The IETF Trust (2007). 798 This document is subject to the rights, licenses and restrictions 799 contained in BCP 78, and except as set forth therein, the authors 800 retain all their rights. 802 This document and the information contained herein are provided on an 803 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 804 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 805 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 806 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 807 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 808 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 810 Intellectual Property 812 The IETF takes no position regarding the validity or scope of any 813 Intellectual Property Rights or other rights that might be claimed to 814 pertain to the implementation or use of the technology described in 815 this document or the extent to which any license under such rights 816 might or might not be available; nor does it represent that it has 817 made any independent effort to identify any such rights. Information 818 on the procedures with respect to rights in RFC documents can be 819 found in BCP 78 and BCP 79. 821 Copies of IPR disclosures made to the IETF Secretariat and any 822 assurances of licenses to be made available, or the result of an 823 attempt made to obtain a general license or permission for the use of 824 such proprietary rights by implementers or users of this 825 specification can be obtained from the IETF on-line IPR repository at 826 http://www.ietf.org/ipr. 828 The IETF invites any interested party to bring to its attention any 829 copyrights, patents or patent applications, or other proprietary 830 rights that may cover technology that may be required to implement 831 this standard. Please address the information to the IETF at 832 ietf-ipr@ietf.org. 834 Acknowledgment 836 Funding for the RFC Editor function is provided by the IETF 837 Administrative Support Activity (IASA).