Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs:
TBD

RAI Area Director(s):
TBD

RAI Area Advisor:
Allison Mankin

Mailing Lists:
General Discussion: p2p-sip@cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group

The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol
working group (P2PSIP WG) is to develop guidelines and mechanisms for
the use of the Session Initiation Protocol (SIP) in settings where
establishing and managing sessions is either partially or entirely
handled by a collection of endpoints (peers) rather than centralized
servers. This is an alternative to the conventional SIP approach which
relies on service provider hosted proxies to which users get assigned
by out-of-band means, usually based on geography, association, or
business reasons.

This is motivated by scenarios where a reduction in cost of equipment
and operation for non-end users is desired, and in situations where
such servers are not available. Some of the scenarios identified
include:

1. Self-organizing and highly available proxy farms, as opposed to the
   fixed hierarchy of IMS-like systems.

2. Topologies with ephemeral relationships such as small office
   systems (with little or no central equipment), mesh networks,
   emergency response, and battlefield environments. These systems may
   have limited or no connectivity to the Internet. 

3. Recovery functions to allow endpoints to communicate in the event a
   central server fails or the endpoints are isolated by a network
   partitioning event.

The working group starts with the following general assumptions:

1. Peer associations groups, which may be called "P2P networks", "P2P
   overlays", or "P2P federations" will provide namespaces within
   which P2P-SIP resources are identified. These namespaces are
   bounded by the identifier(s) of the peer association group, which
   may map to domain-level identifiers in the DNS.

2. Session establishment, capabilities negotiation, session
   termination, subscription, notification, messaging, and related
   functions traditionally performed using SIP will continue to be
   performed using SIP. This working group is interested only in the
   mechanisms for locating resources within peer association
   groups. We generally refer to this as the "rendezvous problem".

3. Some elements of each peer association group MAY be rooted in the
   DNS such that they can be used for bootstrapping operations.
   However, a peer association group that is operating entirely in an
   isolated (or disconnected, or autonomous) mode will rely on
   alternate means of bootstrapping the peer association group.

4. Interactions between peer association groups (or members thereof)
   and other peer association groups or conventional SIP installations
   will be resolved using the resource location model of RFC 3263:
   "Locating SIP Servers".

5. The level of authenticity of identity will vary by the peer
   association group. However, the working group will define at least
   one mechanism that will provide assertion of identity having
   strength equivalent to that provided by the "SIP Identity
   Mechanism" RFC, perhaps by reusing some or all of the mechanism of
   that RFC.

Specifically, the working group will:

1. Document scenarios in which a P2P architecture is appropriate for
   SIP based solutions ("use-cases" document).

2. Develop a general architecture or framework for P2P-based SIP
   applications. This will require evaluating the existing deployed
   and proposed P2P-based SIP solutions for possible incorporation
   into this work.

3. Define a distributed location mechanism for locating users in the
   absence of a central server, including the protocols and algorithms
   needed do establish, maintain, and query the distributed
   information.

4. If SIP extensions are needed to support the peer-to-peer model,
   define requirements for those extensions to be acted on by the SIP
   working group.

5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate
   them into the P2P SIP architecture or framework.  If necessary,
   define requirements for enhancements of existing techniques to be
   acted on by other working groups.

While ensuring:

1. Security is addressed in these systems.

2. Interoperability with existing client-server (CS) SIP and the PSTN.

3. The solutions proposed will function even with some or many nodes
   located behind NATs or firewalls.

4. Existing protocols are reused whenever possible.

The following topics are initially out of the Working Group's scope,
but may be considered in possible future charters:

1. Using P2P mechanisms to manage groups of distributed media relays.

2. Using distributed relays to enable anonymous communications.

3. Creating distributed voice mail systems.

4. Performing distributed search for users based on something other
   than user id.

The following topics are explicitly excluded from the Working Group's
scope:

1. Issues specific to applications other than locating users and
   resources for the full range of SIP-based communications offered
   in a conventional client-server SIP system, including but not
   limited to real-time media, messaging, and presence.

2. Discussion of this technology as a replacement for conventional
   (client-server) SIP.

3. Solving "research" type open questions related to P2P SIP. The
   working group will instead forward such work to the IRTF. A few
   such topics include:
   o Fully distributed schemes for assuring unique user identities.
   o Development of new structured P2P algorithms, such as DHTs.
   o Developing a P2P-based replacements for DNS.

The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF. Respecting the IETF specification change policy, the working
group will refer any possible changes or extensions as suggestions to
the appropriate WGs as needed. A guiding principal of the WG will be
to avoid extensions or change wherever possible.

Goals and Milestones
Aug 2006        Submit use-cases document to the IESG (Informational)
Jan 2007        Submit architecture document to the IESG (Informational)
Jul 2007        Submit protocol and/or protocol extension documents to
                the IESG (Standards-track)