P2PSIP Draft Charter Dean Willis March 2006
Purpose 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.
Scenarios 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.
Assumption 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. Means: externally visible identifiers are domain-scoped -- bob@example.com
Assumption 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". Means: Use regular SIP mechanisms for everything except location database.
Assumption 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. Means: Bootstrap using DNS when we have it. Use something else when we don t.
Assumption 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". Means: Use Regular SIP between overlays
Assumption 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. Means: Need at least one centralized identity mechanism.
Tasks 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.
Mission Parameters 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 (perhaps almost all) nodes located behind NATs or firewalls. 4. Existing protocols are reused whenever possible.
Excluded from Initial Scope 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 distinguished name.
Out of 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: 1. Fully distributed schemes for assuring unique user identities. 2. Development of new structured P2P algorithms, such as DHTs. 3. Developing a P2P-based replacements for DNS.
Cooperation 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
Proposed Milestones December 2006 Use Cases and Requirements May 2007 Architecture and Framework December 2007 Protocol Documents