One document matched: draft-bryan-p2psip-app-scenarios-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- you can convert this to html with xsltproc and rfc2629.slt
see http://xml.resource.org/ and rfc 2629 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<rfc category="info" docName="draft-bryan-p2psip-app-scenarios-00" ipr="full3978">
<front>
<title abbrev="P2PSIP Application Scenarios">Application Scenarios for Peer-to-Peer Session
Initiation Protocol (P2PSIP)</title>
<author fullname="David A. Bryan" initials="D. A." surname="Bryan">
<organization>SIPeerior Technologies, Inc.</organization>
<address>
<postal>
<street>3000 Easter Circle</street>
<city>Williamsburg</city>
<region>VA</region>
<code>23188</code>
<country>USA</country>
</postal>
<phone>+1 757 565 0101</phone>
<email>dbryan@sipeerior.com</email>
</address>
</author>
<author fullname="Eunsoo Shim" initials="E." surname="Shim">
<organization abbrev="Locus Telecom">Locus Telecommunications,
Inc.</organization>
<address>
<postal>
<street>2200 Fletcher Ave. 6th FL</street>
<street></street>
<city>Fort Lee</city>
<region>NJ</region>
<code>07024</code>
<country>USA</country>
</postal>
<email>eunsoo@locus.net</email>
</address>
</author>
<author fullname="Bruce B. Lowekamp" initials="B. B." surname="Lowekamp">
<organization>SIPeerior; William & Mary</organization>
<address>
<postal>
<street>3000 Easter Circle</street>
<city>Williamsburg</city>
<region>VA</region>
<code>23188</code>
<country>USA</country>
</postal>
<phone>+1 757 565 0101</phone>
<email>lowekamp@sipeerior.com</email>
</address>
</author>
<author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="editor">
<organization abbrev="Huawei (USA)">Huawei Technologies (USA)</organization>
<address>
<postal>
<street> 1547 Rivercrest Blvd.</street>
<city> Allen</city> <region>TX </region>
<code>75002 </code> <country>USA</country> </postal>
<phone>+1 214 755 3870</phone>
<email>spencer@mcsr-labs.org </email>
</address>
</author>
<date month="November" year="2007" />
<area>RAI</area>
<workgroup>P2PSIP</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Mime</keyword>
<abstract>
<t>This document attempts to identify and classify application scenarios of P2P
based SIP. It does not attempt to exhaustively enumerate these scenarios,
and is focused exclusively on scenarios related to real-time IP
communication.</t>
</abstract>
</front>
<middle>
<section anchor="sectIntro" title="Introduction">
<t>This document attempts to identify and classify application scenarios for
Peer-to-Peer (P2P) based Session Initiation Protocol (SIP) <xref
target="RFC3261"></xref>. Identifying application scenarios will help to understand
and clarify requirements of P2PSIP. In particular, these application scenarios will
assist the P2PSIP community in identifying commonalities and differences between requirements
for different application scenarios, which in turn will help define the
near-term scope of specifications and provide a perspective on future
specifications.</t>
<t>Only application scenarios related to real-time IP communications, such as VoIP,
Instant Messaging (IM), and presence are considered in this document.
Application scenarios of other kinds, even if interesting and possibly useful
applications of P2PSIP, are out of scope for this document. Thus, application
scenarios described herein are application scenarios of P2P IP real-time communications,
and P2PSIP is a protocol choice rather than a constraining factor for
most of them. In describing application scenarios, no deliberation on implementation
is provided. Some of the application scenarios presented may already be implemented
or deployed, possibly using proprietary technology.</t>
<t> The list of application scenarios compiled here is by no means a
complete list of uses cases of P2PSIP, and further cases would be
limited only by the imagination. P2PSIP participants who expect to use P2PSIP technology
for application scenarios that don't match any of the combinations of attributes included in this
document are invited to contribute descriptions of additional application scenarios to the
P2PSIP working group mailing list.</t>
<t>We tried to capture the deployment characteristics of the application scenarios such as
whether the nodes will span over multiple physical network administrative domains or whether the
ID must be controlled by a central authority. The characteristics are presented as scenario-attribute tables.
The values in the tables are what we think are most likely and we understand there may be similar scenarios
with different choices for some attribute values.</t>
<t>Some of these application scenarios, while difficult to implement using a
traditional client server SIP (CS SIP) architecture may not require P2P
and could be implemented in other ways. While these have often been
presented as scenarios calling for P2P communication, the authors
recognize that other technologies may also be applicable to these application
scenarios.</t>
<t>Since the original iteration of this document, the P2PSIP WG has been
formed and numerous documents have been submitted that include some
number of application scenarios. We will not try to enumerate them here. This draft
draws from these documents, as well as discussions at the P2PSIP ad-hoc
and WG meetings and numerous mailing list and personal conversations of
the authors.</t>
</section>
<section anchor="sectTermi" title="Terminology">
<t>We use terminology defined in <xref target="RFC3261">RFC 3261</xref>
in this document without further definition.</t>
<t>We use terminology defined in <xref
target="I-D.willis-p2psip-concepts">Concepts and Terminology for Peer to
Peer SIP</xref> draft in this document without further definition.</t>
<t>We define the attributes used in the discussion of each application scenario
in <xref target="attributes"></xref>.</t>
</section>
<section anchor="attributes" title="Application Scenario Attributes">
<t> The attributes used in the application scenarios matrixes in subsequent sections are explained here.</t>
<t>
<list style='hanging' hangIndent='6'>
<t hangText="Application Scenario:">
The name of an application scenario (previously called a "use case").</t>
<t hangText="Section in Draft:">
A cross-reference to the section number in this draft where the application
scenario is described.</t>
<t hangText="Number of Peers:">
The number of peers that will be active in an overlay at any given point in time.</t>
<t hangText="Number of Users:">
The number of users that will be served by an overlay at any given point in time.</t>
<t>Note that if there are more users than peers, this implies that some client protocol is required,
whether "client protocol" is a P2PSIP client protocol or the SIP protocol
(if the P2PSIP overlay is also providing
<xref target="RFC3263">RFC 3263</xref>-style routing for unmodified SIP clients).</t>
<t hangText="Overlay spans administrative domains:">
Whether the overlay spans across multiple physical network administrative domains.
If "yes",
this makes IP multicast and centralized operations and management unlikely.</t>
<t hangText="Multicast Available:">
Whether "application-level multicast", "IP multicast", or "link multicast"
may be available for a typical overlay.</t>
<t>Note that these are ordered - link multicast implies IP multicast could be available, and
IP multicast implies application-level multicast could be available.</t>
<t hangText="P2P Client Support:">
Whether the overlay need to support a P2P Client protocol, i.e., whether the overlay contains
P2P Clients as well as Peers.</t>
<t hangText="Interoperation with CS-SIP:">
Whether the overlay must also interact with legacy SIP clients and SIP proxies.</t>
<t>Note that one or more peers in the overlay may also act as PSTN gateways.</t>
<t hangText="Non-stop Operation:">Whether this application scenarios allows the overlay to become
unavailable for periods of time (for example, could an overlay stop operating in order
to change DHT algorithms, or would the overlay have to support two DHT algorithms in
"ships in the night" mode?)</t>
<t hangText="Centralized Operations and Management:">
Whether any centralized operations/management entity is responsible for successful operation of
the overlay.</t>
<t hangText="Centralized ID Control:">
Whether ID assignment by central authority is required within an overlay (basically,
whether the overlay can be Sybil-attacked - the theory is that if IDs are controlled by
a centralized entity, overlay operators simply remove misbehaving users from the
authorization registry).</t>
<t hangText="Supports Anonymous Users:">
Whether this application scenario allows users to connect to an overlay without providing
any identity.</t>
<t hangText="Carrier-Class Robustness:">
Whether the overlay must provide reliable storage and retrieval in the face of node failure.</t>
<t hangText="NATs within a single overlay">
Whether the peer protocol must expect to perform NAT traversal as part of normal operation.</t>
<t hangText="DNS available:">
Whether DNS is available so that peers may perform DNS lookups as part of the overlay JOIN
operation.</t>
<t hangText="End-to-end SIP Encryption:">
Whether this application scenario requires SIP traffic between two peers to be
encrypted, so SIP requests and responses are not visible to intermediate peers (peers
that forward traffic between two peers that aren't directly connected).
In these cases, hop-by-hop TLS encryption, although appropriate when traversing trusted
SIP Proxies, is not appropriate when traversing untrusted P2PSIP Peers.</t>
</list>
</t>
</section>
<section anchor="appscen" title="Application Scenarios">
<t>Application scenarios are grouped according to the characteristics of the network
environment in which the end users or devices participating in the P2P
overlay are communicating with each other.</t>
<section title="Global Internet Environment">
<t>The global Internet environment consists of a large number of
autonomous networks with diverse characteristics. Thus, there is no
central administration or network control of the physical network on a
global scale. Communication paths between two remote devices may span
multiple administrative domains and should be assumed to be insecure.
Note that most well-known P2P file sharing overlay networks have
operated in this environment.</t>
<section title="Public P2P VoIP Service Providers">
<t>Skype is an outstanding example of a public VoIP service provider
using P2P technology among end user devices, although Skype uses a
proprietary protocol. Recent research has shown <xref
target="skypestudy"></xref> that Skype uses a central login server,
responsible for management of registered user names. End users are
authenticated via a certificate signed by a central server. End user
devices are distributed across the global Internet. The number of
participating end user devices is very large. A major motivation of
using P2P between end user devices for a commercial VoIP service is
a reduction in infrastructure and operational costs.</t>
<t><xref target="table_4.1.1"> </xref> provides a high-level overview of this category.</t>
<texttable anchor='table_4.1.1'>
<ttcol align='center'> Application Scenario </ttcol> <ttcol align='center'> Public P2P VoIP Service Providers </ttcol> <ttcol align='center'> Open Global P2P VoIP Network </ttcol>
<c> Section in Draft </c> <c> 4.1.1 </c> <c> 4.1.2 </c>
<c> Number of Peers </c> <c> hundreds </c> <c> thousands </c>
<c> Number of Users </c> <c> millions </c> <c> millions </c>
<c> Overlay spans administrative domains </c> <c> no </c> <c> yes </c>
<c> Multicast Available </c> <c> no </c> <c> no </c>
<c> P2P Client Support </c> <c> yes </c> <c> yes </c>
<c> Interaction with CS-SIP </c> <c> yes </c> <c> yes </c>
<c> Non-stop Operation </c> <c> yes </c> <c> yes </c>
<c> Centralized Operations and Management </c> <c> yes </c> <c> yes </c>
<c> Centralized ID Control </c> <c> yes </c> <c> no </c>
<c> Supports Anonymous Users </c> <c> no </c> <c> no </c>
<c> Carrier-Class Robustness </c> <c> yes </c> <c> yes </c>
<c> NATs within a single overlay </c> <c> yes </c> <c> yes </c>
<c> DNS available </c> <c> yes </c> <c> yes </c>
<c> End-to-end SIP Encryption </c> <c> yes </c> <c> yes </c>
<postamble> Public P2P VoIP Service Providers and Open Global P2P VoIP Network </postamble>
</texttable>
</section>
<section title="Open Global P2P VoIP Network">
<t>This is a global P2P VoIP network in which there is no central
authority such as a single service provider. Anyone can join and
leave the network freely and anyone can implement the software to
participate in the overlay network. In such a system, the protocols
used must be based on open standards. This P2P VoIP network
resembles the global Internet itself in that it has distributed
management and growth, enables anyone to reach anyone else in the
overlay network, and any device supporting the standard protocols
can be used. </t>
<t><xref target="table_4.1.1"> </xref> provides a high-level overview of this category.</t>
</section>
<section title="Wide Area Networks of Consumer Electronics Devices">
<t>Instant messaging application
software provides presence, text and media messaging, and
file transfer capabilities between online users. As more and
more multimedia
consumer electronics devices such as cameras, camcorders and
televisions become network aware, instant sharing of multimedia
content such as photos and video clips between family members and
friends will be desirable. VoIP may not be needed on some of these
consumer electronics devices, however in other cases such as
gaming, voice communication between users may be highly
desirable. As consumer electronics providers may desire to
provide these capabilities without investing in extensive
server capabilities, a global P2P network supporting presence is an
important infrastructure component for this application scenario.</t>
<t><xref target="table_4.1.3"> </xref> provides a high-level overview of this category.</t>
<texttable anchor='table_4.1.3'>
<ttcol align='center'> Application Scenario </ttcol> <ttcol align='center'> Wide Area Networks of Consumer Electronics Devices </ttcol>
<c> Section in Draft </c> <c> 4.1.3 </c>
<c> Number of Peers </c> <c> thousands </c>
<c> Number of Users </c> <c> millions </c>
<c> Overlay spans administrative domains </c> <c> yes </c>
<c> Multicast Available </c> <c> no </c>
<c> P2P Client Support </c> <c> yes </c>
<c> Interaction with CS-SIP </c> <c> no </c>
<c> Non-stop Operation </c> <c> no </c>
<c> Centralized Operations and Management </c> <c> maybe </c>
<c> Centralized ID Control </c> <c> maybe </c>
<c> Supports Anonymous Users </c> <c> no </c>
<c> Carrier-Class Robustness </c> <c> no </c>
<c> NATs within a single overlay </c> <c> yes </c>
<c> DNS available </c> <c> yes </c>
<c> End-to-end SIP Encryption </c> <c> no </c>
<postamble> Wide Area Networks of Consumer Electronics Devices </postamble>
</texttable>
</section>
<section title="Multimedia content sharing via Application Layer Multicasting (Content Providers or Ad Hoc)">
<t>IP-layer multicasting is not generally available beyond the
boundary of single IP subnet. Application layer multicasting has
become a plausible alternative to IP-layer multicasting. In
application layer multicasting, the nodes that need to receive the
content from the same source form a distribution network, typically
of a tree-like topology, and relay the received content to other
nodes in the distribution network. This technique can be used to
multicasting video or audio stream to a number of nodes distributed
over the Internet (or across multiple IP subnets). </t>
<t>Note that this application scenario covers two types of deployments -
large-scale commercial audio or video
distribution/broadcasting services such as Internet radio or TV
services ("Content Provider") or to ad-hoc video sharing among a group of friends ("Ad Hoc").</t>
<t><xref target="table_4.1.4"> </xref> provides a high-level overview of this category.</t>
<texttable anchor='table_4.1.4'>
<ttcol align='center'> Application Scenario </ttcol> <ttcol align='center'> Multimedia content sharing via Application Layer Multicasting (Content Providers) </ttcol> <ttcol align='center'> Multimedia content sharing via Application Layer Multicasting (Ad Hoc) </ttcol>
<c> Section in Draft </c> <c> 4.1.4 </c> <c> 4.1.4 </c>
<c> Number of Peers </c> <c> hundreds </c> <c> hundreds </c>
<c> Number of Users </c> <c> thousands </c> <c> thousands </c>
<c> Overlay spans administrative domains </c> <c> yes </c> <c> yes </c>
<c> Multicast Available </c> <c> application multicast </c> <c> application multicast </c>
<c> P2P Client Support </c> <c> yes </c> <c> yes </c>
<c> Interaction with CS-SIP </c> <c> no </c> <c> no </c>
<c> Non-stop Operation </c> <c> yes </c> <c> no </c>
<c> Centralized Operations and Management </c> <c> yes </c> <c> no </c>
<c> Centralized ID Control </c> <c> yes </c> <c> no </c>
<c> Supports Anonymous Users </c> <c> no </c> <c> no </c>
<c> Carrier-Class Robustness </c> <c> yes </c> <c> no </c>
<c> NATs within a single overlay </c> <c> yes </c> <c> yes </c>
<c> DNS available </c> <c> yes </c> <c> yes </c>
<c> End-to-end SIP Encryption </c> <c> yes </c> <c> no </c>
<postamble> Multimedia content sharing via Application Layer Multicasting (Content Provider and Ad Hoc) </postamble>
</texttable>
</section>
</section>
<section title="Environments with Limited Connectivity to the Internet or Infrastructure">
<t>When there is no physical network available for stable deployment
of client server SIP or an instant deployment of real-time
communication systems is required, the P2P approach may be the only
feasible solution. Examples of such environment are isolated wireless
ad-hoc networks with no connection to the Internet or ad-hoc networks
with limited connectivity to the Internet in situations like outdoor
public events, emergencies, and battlefields. Any type of manual
configuration is difficult to achieve because technical support is not
readily available in such environment. In some cases, connectivity to
the global Internet may be available, but be very expensive, of
limited capacity, or unstable, such as satellite connections. In such
cases, it is preferable to localize communications as much as
possible, reducing dependency on any infrastructure in the global
Internet.</t>
<t><xref target="table_4.2"> </xref> provides a high-level overview of this category.</t>
<texttable anchor='table_4.2'>
<ttcol align='center'> Application Scenario </ttcol> <ttcol align='center'> Ad-Hoc and Ephemeral Groups </ttcol> <ttcol align='center'> Extending the Reach of Mobile Devices </ttcol> <ttcol align='center'> Impeded Access </ttcol> <ttcol align='center'> Local Area Networks of Consumer Electronics Devices </ttcol>
<c> Section in Draft </c> <c> 4.2.1 </c> <c> 4.2.2 </c> <c> 4.2.3 </c> <c> 4.2.4 </c>
<c> Number of Peers </c> <c> tens </c> <c> hundreds </c> <c> hundreds </c> <c> tens </c>
<c> Number of Users </c> <c> tens </c> <c> hundreds </c> <c> hundreds </c> <c> tens </c>
<c> Spans administrative domains </c> <c> no </c> <c> no </c> <c> yes </c> <c> no </c>
<c> Multicast Available </c> <c> link multicast </c> <c> link multicast </c> <c> no </c> <c> link multicast </c>
<c> P2P Client Support </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> Interaction with CS-SIP </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> Non-stop Operation </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> Centralized Operations and Management </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> Centralized ID Control </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> Supports Anonymous Users </c> <c> yes </c> <c> yes </c> <c> yes </c> <c> yes </c>
<c> Carrier-Class Robustness </c> <c> no </c> <c> no </c> <c> no </c> <c> no </c>
<c> NATs within a single overlay </c> <c> no </c> <c> no </c> <c> yes </c> <c> no </c>
<c> DNS available </c> <c> no </c> <c> no </c> <c> yes </c> <c> yes </c>
<c> End-to-end SIP Encryption </c> <c> no </c> <c> no </c> <c> yes </c> <c> no </c>
<postamble> Environments with Limited Connectivity to the Internet or Infrastructure </postamble>
</texttable>
<section title="Ad-Hoc and Ephemeral Groups">
<t>Groups of individuals meeting together have need for
collaborative communications systems that are ephemeral in nature,
have minimum (ideally zero) configuration, and do not depend on
connectivity to the Internet. These scenarios require an arbitrary
number of users to connect communications devices. These
can include cases where Internet connectivity due to
remote location, inability to pay for connectivity, or
following a natural disaster where service is interrupted.</t>
<t>Example: A group gets together for a meeting, but there is no
Internet connectivity. If the users establish a wireless ad hoc
network or have a base station, all users may connect and establish
chat sessions using an IM protocol with no need for server
configuration.</t>
<t>Example: Following a disaster, the local fire department arrives.
Each fire fighter has a wireless handset, and one or more trucks
have wireless base stations. When a nearby locality sends additional
rescuers, their wireless handsets should be able to instantly join
the communications network and communicate, without the
need for central configuration.</t>
</section>
<section title="Extending the Reach of Mobile Devices">
<t><cref>Spencer has misgivings about "Extending the Reach of Mobile Devices", based on
(1) relaying at the link layer or at the
network layer would make more sense, and would work for devices that do not support P2PSIP, and (2)
although small networks might work well enough when peers simply forward a request "around the overlay",
in larger networks
the problem space morphs from forwarding traffic in *the* direction of
a destination to routing traffic in the *best* direction to the destination - a much harder problem.
</cref></t>
<t>A network of mobile devices can relay traffic between themselves
to reach a base station, even if the base station is out of reach of
that device.</t>
<t>Example: A user has a handset for communication that cannot reach
a base station. Some other user is within range of both that user
and a base station. This intermediate user can serve as a relay for
the caller who is out of range. A system might make this feature
optional for standard communication and mandatory for E911.</t>
</section>
<section title="Impeded Access">
<t>Certain groups may have their ability to communicate impeded.
These users should be able to communicate without the need to
connect to any centralized servers, which may be blocked by
providers upstream of the user. A fully decentralized system cannot
be completely disconnected without removing connectivity at the
basic Internet level.</t>
<t>Example: A user wishes to use an IP telephony service to
communicate PC to PC with a friend, but the ports commonly used by
these services, or the servers used for authentication, are
blocked by the ISP because the ISP also offers communications
systems and have a vested interest in denying access to external communications systems.</t>
<t>Example: A user with an Internet enabled PDA devices wishes to connect
with colleagues, but traditional services are blocked to ensure that
SMS or voice minutes are used (at additional cost) instead.</t>
</section>
<section title="Local Area Networks of Consumer Electronics Devices">
<t>In addition to consumer devices sharing information with
other users across the Internet, having devices that can
locate each other and exchange information within the local
LAN of a particular user may also be an attractive
application. In this case, devices could use P2PSIP to
locate multimedia resources available on other devices and
stream the information between the devices.
</t>
<t>Example: A user wishes to share content among consumer electronics devices within a home network.</t>
</section>
</section>
<section title="Managed, Private Network Environments">
<t>A corporate network or a school campus network is an example of the
managed, private network environment. Most likely client server SIP
can be used and managed for real-time communication applications in
these environments. However, in certain scenarios, P2PSIP may be used
instead or as a complementary means, to achieve various goals such as
cost and management overhead reduction, scalability, and system
robustness.</t>
<t><xref target="table_4.3"> </xref> provides a high-level overview of this category.</t>
<texttable anchor='table_4.3'>
<ttcol align='center'> Application Scenario </ttcol> <ttcol align='center'> Serverless or Small Scale IP-PBX </ttcol> <ttcol align='center'> P2P for Redundant SIP Servers </ttcol> <ttcol align='center'> Failover for Centralized Systems </ttcol>
<c> Section in Draft </c> <c> 4.3.1 </c> <c> 4.3.2 </c> <c> 4.3.3 </c>
<c> Number of Peers </c> <c> hundreds </c> <c> hundreds </c> <c> tens </c>
<c> Number of Users </c> <c> hundreds </c> <c> hundreds </c> <c> tens </c>
<c> Spans administrative domains </c> <c> no </c> <c> no </c> <c> no </c>
<c> Multicast Available </c> <c> IP multicast </c> <c> IP multicast </c> <c> IP multicast </c>
<c> P2P Client Support </c> <c> no </c> <c> no </c> <c> no </c>
<c> Interaction with CS-SIP </c> <c> yes </c> <c> no </c> <c> yes </c>
<c> Non-stop Operation </c> <c> yes </c> <c> yes </c> <c> yes </c>
<c> Centralized Operations and Management </c> <c> maybe </c> <c> yes </c> <c> yes </c>
<c> Centralized ID Control </c> <c> self-cert? </c> <c> yes </c> <c> yes </c>
<c> Supports Anonymous Users </c> <c> no </c> <c> no </c> <c> no </c>
<c> Carrier-Class Robustness </c> <c> no </c> <c> yes </c> <c> yes </c>
<c> NATs within a single overlay </c> <c> yes </c> <c> no </c> <c> no </c>
<c> DNS available </c> <c> no </c> <c> yes </c> <c> yes </c>
<c> End-to-end SIP Encryption </c> <c> no </c> <c> no </c> <c> no </c>
<postamble> Managed, Private Network Environments </postamble>
</texttable>
<section title="Serverless or Small Scale IP-PBX">
<t>Many small enterprises have a need for integrated communications
systems. These systems have slightly different requirements than
more traditional IP PBXs. For small enterprises, there may be no
administrator for these systems, requiring the systems to be
essentially self-configuring and/or self-organizing. Additional
endpoints should be able to be added with no requirements for
configuration on central devices.</t>
<t>These systems should offer the feature sets similar to those of
client server type PBX systems. Connectivity to the PSTN is an
important feature for these systems. In addition, they may support
features such as call transfer, voice mail, and possibly even other
communications modes such as instant messaging or media features
such as video or conference services. There are already commercial
products of this type.</t>
<t>Example: Small organizations without centralized IT</t>
</section>
<section title="P2P for Redundant SIP Proxies">
<t>Service providers may wish to connect a farm of proxies together
in a transparent way, passing resources (user registrations or other
call information) between themselves with as little configuration or
traffic as possible. Ideally, the redundancy and exchange of
information should require a minimum of configuration between the
devices. P2P architecture between the proxies allows proxy farms
to be organized and operated in this way. With this approach, it is
easy to add more proxies with minimal service disruptions and
increases the robustness of the system.</t>
<t>Example: a SIP service provider may wish to scale SIP proxies by
using a P2PSIP overlay that provides <xref target="RFC3263">RFC 3263</xref> request routing services,
instead of using either front-end load balancing devices or making
the structure of the proxy farm visible outside the proxy farm itself.</t>
</section>
<section title="Failover for Centralized Systems">
<t>A traditional centralized SIP server, such as used in an IP-PBX,
forms a single point of failure of an otherwise fault-independent
network. Relying on P2PSIP as a backup to the centralized server
allows the communications system to continue functioning normally in
the event of planned or unplanned service interruptions of the
central IP-PBX. When combined with a low-configuration
P2PSIP PBX, this can provide a simple, standalone
communications system for the developing world that allows
local communication even when Internet connectivity is severed.</t>
<t>Example: A small company has a central IP-PBX. When that device
experiences a failure, the handsets are able to transparently
continue operation for the 24 hours it takes to obtain a replacement
switch.</t>
<t>Example: A village in the developing world has connectivity that
is limited by weather (microwave connection) or is solar powered. It
would be desirable for intra-village communication to continue to
function in the absence of Internet connectivity.</t>
</section>
</section>
</section>
<section title="Changes from draft-bryan-p2psip-usecases-00">
<t>This draft builds on the analysis done for an earlier draft, draft-bryan-p2psip-usecases-00, now expired.
For ease of reference, <xref target="table_changes"> </xref> shows the mapping of use cases described in
draft-bryan-p2psip-usecases-00 onto the application scenarios described in this document.</t>
<texttable anchor='table_changes'>
<ttcol align='center'> Use Case </ttcol> <ttcol align='center'> Section in Use Cases Draft </ttcol> <ttcol align='center'> Application Scenario </ttcol>
<c> Public P2P VoIP Service Providers </c> <c> 3.1.1 </c> <c> (no change) </c>
<c> Open Global P2P VoIP Network </c> <c> 3.1.2 </c> <c> (no change) </c>
<c> Presence Using Multimedia Consumer Electronics Devices </c> <c> 3.1.3 </c> <c> Split into (Content Provider) and (Ad Hoc) scenarios </c>
<c> Multimedia content sharing via Application Layer Multicasting </c> <c> 3.1.4 </c> <c> (no change) </c>
<c> Impeded Access </c> <c> 3.2.1 </c> <c> (no change) </c>
<c> Anonymous Communications </c> <c> 3.2.2 </c> <c> Became an attribute of other scenarios </c>
<c> Security Conscious Small Organizations </c> <c> 3.2.3 </c> <c> Became an attribute of other scenarios </c>
<c> Ad-Hoc and Ephemeral Groups </c> <c> 3.3.1 </c> <c> (no change) </c>
<c> Emergency First Responder Networks </c> <c> 3.3.2 </c> <c> Merged with Ad-Hoc and Ephemeral Groups </c>
<c> Extending the Reach of Mobile Devices </c> <c> 3.3.3 </c> <c> (no change) </c>
<c> Deployments in the Developing World </c> <c> 3.3.4 </c> <c> Merged with Failover </c>
<c> Serverless or Small Scale IP-PBX </c> <c> 3.4.1 </c> <c> (no change) </c>
<c> P2P for Redundant SIP Servers </c> <c> 3.4.2 </c> <c> (no change) </c>
<c> Failover for Centralized Systems </c> <c> 3.4.3 </c> <c> (no change) </c>
<postamble> Changes from draft-bryan-p2psip-usecases-00 </postamble>
</texttable>
</section>
<section title="Acknowledgments">
<t>The following persons have contributed application scenarios or ideas
to this document:</t>
<t>Cullen Jennings, Philip Matthews, Henry Sinnreich, Adam Roach, Robert
Sparks, Kundan Singh, Henning Schulzrinne, K. Kishore Dhara, and Salman
A. Baset.</t>
</section>
<section title="Security Considerations">
<t>The security requirements of the various application scenarios vary tremendously.
They should be discussed in more detail in this document.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA Considerations.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.willis-p2psip-concepts"?>
&rfc3261;
&rfc3263;
</references>
<references title="Informative References">
<reference anchor="skypestudy">
<front>
<title>An Analysis of the Skype Peer-to-Peer Internet Telephony
Protocol</title>
<author fullname="Salman A. Baset" initials="S. A." surname="Baset">
<organization>Columbia University</organization>
</author>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="September" year="2004" />
</front>
<seriesInfo name="Technical Report, Department of Computer Science, Columbia University"
value="0309-04" />
<format target="http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf"
type="PDF" />
</reference>
</references>
</back>
</rfc>
<!-- LocalWords: bryan
-->
| PAFTECH AB 2003-2026 | 2026-04-23 20:47:08 |