One document matched: draft-stiemerling-p2psip-impl-00.txt
P2PSIP M. Stiemerling
Internet-Draft M. Brunner
Intended status: Standards Track NEC
Expires: April 18, 2007 M. Cassini
Uni Turin
October 15, 2006
Peer-to-Peer SIP Implementation Report
draft-stiemerling-p2psip-impl-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo is an implementation report about the peer-to-peer SIP
system developed in the European IST Ambient Networks research
project. This system replaces the traditional SIP proxy-registrar
Stiemerling, et al. Expires April 18, 2007 [Page 1]
Internet-Draft P2PSIP Implementation October 2006
function with a distributed lookup mechanism, adds overlay
functionality to the SIP signalling and to RTP traffic, takes care
about media/packet relay lookup and insertion into the SIP/RTP paths.
Standard SIP user agents are used for communication. The presented
system is work in progress.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SATO System Overview . . . . . . . . . . . . . . . . . . . . . 4
2.1. General concepts of SATO . . . . . . . . . . . . . . . . . 4
2.2. Elements of SATO . . . . . . . . . . . . . . . . . . . . . 5
3. Running Peer-to-Peer SIP . . . . . . . . . . . . . . . . . . . 6
3.1. Registering and Deregistering a User . . . . . . . . . . . 6
4. Running a P2P Call . . . . . . . . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Stiemerling, et al. Expires April 18, 2007 [Page 2]
Internet-Draft P2PSIP Implementation October 2006
1. Introduction
This memo is an implementation report about the peer-to-peer SIP
system developed in the European IST Ambient Networks research
project. The presented system is work in progress and focusses on
voice/video calls but does currently not consider presence and
instant messaging.
The spread of Internet technology in many types of wireless networks,
presenting different features and technologies, has been a revolution
for the networking architecture, traditionally based on fixed
networks. Nowadays, the interconnection of systems presenting
heterogeneous network capabilities, access technologies and end-user
devices is becoming a must for many applications and services.
The European Community's Sixth Framework Program Integrated Project
called 'Ambient Networks' [AMBIENT] is trying to address these
challenges, following generalization and integration procedures. The
main ob jective of the pro ject is the definition of a complete
innovative networking model, respondent to the development of mobile
network solutions and the integration of different types of fixed and
mobile networks.
One of the main interests in this kind of network organization is the
provision of services to the end-users, in a way transparent to the
network specific characteristics as much as possible. In this
research area, Overlay Networks have been proved to be a powerful
solution for abstracting services from the network connectivity and
providing a decentralized network organization.
Ambient Networks is defining an overlay service of Service-aware
Adaptive Transport Overlay (SATO). The main purpose is the design of
a generalized structure which is able to realize overlay networks on
demand, in order to carry multiple applications and to provide them
useful functionalities inside the network paths. The exchange of
multimedia traffic like voice and video is one of the applications
which can benefit of SATO. Peer-to-peer SIP has been realized on the
SATO platform and this memo gives an overview of the current
implementation.
The remainder of the document is structure in this way that Section 2
defines the goals of our peer-to-peer SIP system and introduces the
system. Section 5 reports some findings.
You will find the P2PSIP terminology used within this memo being
mainly aligned with the terminology in [I-D.willis-p2psip-concepts].
Stiemerling, et al. Expires April 18, 2007 [Page 3]
Internet-Draft P2PSIP Implementation October 2006
2. SATO System Overview
This section describes the overall system of the Service-Aware
Transport Overlay (SATO) system used to build a peer-to-peer SIP
system.
2.1. General concepts of SATO
The purpose of SATO in the Ambient Networks architecture is to
provide a flexible and customisable transport service to the
application layer by using overlay networks on top of the transport
layer connectivity. Further service needed to run such a SATO are
included, for instance a distributed lookup service (i.e., DHT but
not limited to).
Service-aware Transport Overlay
Service-aware Adaptive Transport Overlays (SATOs) enable the
flexible configuration of virtual networks consisting of Overlay
Nodes (ONodes) on top of the underlying basic network
connectivity. The Overlay Network topologies are responding to
the application needs and can follow point-to-point, point-to-
multipoint and multipoint-to-multipoint paradigms. Many SATOs can
be created and deployed simultaneously.
Dynamic Inclusion of Network Elements
The novel SATO concept allows the transparent inclusion of
network-side data processing elements (SATO Ports) in the end-to-
end transport path (between a client and a server or Peer-to-
Peer). These SATO Ports can provide value-added functions such as
Overlay routing, smart caching, media adaptation, rate adaptation,
synchronization, filtering, metering, congestion control, etc.
On Demand Overlay Set Up and Tear Down
Service-aware Adaptive Transport Overlays are designed for
accommodating the requests of the application services. As a
consequence, they should be established on demand, based on
particular requirements, and terminated when the service is not
requested anymore (e.g., after the last user has disconnected).
Stiemerling, et al. Expires April 18, 2007 [Page 4]
Internet-Draft P2PSIP Implementation October 2006
Overlay Adaptation
SATOs could adapt as a consequence of ONodes joining or leaving
the virtual network or due to ONodes with changing context or as a
result of adaptation requests from other Ambient Networks
Functional Entities. This introduces the notion of Oadaptive
overlaysO that dynamically re-configure in order to optimise the
service delivery. Dynamic adaptation of a SATO can also take
place in response to changes in other Functional Entities (FEs) or
in the underlying network. SATO adaptation requires significant,
time-consuming control space activities possibly involving
interactions between many FEs. Highly dynamism or fast
alterations within SATOs can therefore be addressed by means of
internal SATO routing capabilities.
2.2. Elements of SATO
The core of the SATO P2PSIP systems are the SATO overlay nodes.
These nodes are P2PSIP overlay peers participating in the peer-to-
peer routing. Each overlay peer hosts a modified SIP proxy, RTP
proxy, and the overlay manager. The overlay manager is in charge of
controlling the overlay, providing a distributed lookup service for
users and media relays, etc. Additionally, overlay peers can host
media relays that are offered to other peers in order to assist in
NAT/firewall traversal. Figure 1 shows the overlay peer building
blocks.
+-------------------------------------------+
| |
| +---------+ +---------+ +---------+ |
| | | | | | | |
| | RTP | |modified |<~~~~>| Overlay | |
| | Proxy <~~> SIP | | Mngr <=====>
| | | | Proxy | | | |
| | | | | | | |
| +----+----+ +----+----+ +---------+ |
| | | |
| v v |
| Overlay Peer |
+-------------------------------------------+
<~~~> Overlay Peer Internal Control
<===> Overlay Peer Protocol
----> IP socket interface
Figure 1: P2PSIP overlay peer
Stiemerling, et al. Expires April 18, 2007 [Page 5]
Internet-Draft P2PSIP Implementation October 2006
The overlay manager uses Web Services (chosen for rapid prototyping
for the P2PSIP Overlay Peer Protocol) to communicate with other
overlay managers on other peer nodes. The overlay peer internal
communication is using Unix sockets. The SIP proxy is using an off
the shelf SIP stack with modified routing, i.e., peer-to-peer
routing, stores the user records in a DHT (see next paragraph), and a
slightly changed interface to the IP sockets. The RTP proxy is off
the shelf as well. The connections between two SIP proxies or two
RTP proxies on different overlay peers can use any type of transport
protocol or network layer setting, e.g., TCP running over IPsec. The
used transport protocol, IP version, encryption, etc is negotiated
via the overlay managers.
Not shown in Figure 1 is the distributed lookup service for storing
P2PSIP overlay user records and location information for media
relays. For both, the user records and the media relay location, a
mapping of the respective information to the IP address of the
overlay peer is stored. The bamboo DHT implementation [BAMBOO] is
currently used for storing this information.
3. Running Peer-to-Peer SIP
The SATO P2PSIP system is build in such a way that traditional SIP UA
can participate without any modification. The SIP UA use their
standard way of SIP and RTP for signalling and media. The SIP UAs in
the example below use SIP with UDP transport. The settings of the
UAs need just to point for the SIP registrar and outbound proxy to
their overlay peer (see also Figure 2. So, all outgoing SIP
signalling messages will be forwarded to the respective P2PSIP
overlay peer.
3.1. Registering and Deregistering a User
This section assumes an in advanced happening enrolment process for
the user with the P2PSIP system. The enrolment process has not been
defined and implemented.
The SIP UA proceeds with the standard registration process as defined
in [RFC3261] either UDP or TCP to the P2PSIP overlay peer, i.e., the
P2PSIP Overlay Client Protocol is standard SIP. The P2PSIP registrar
(part of the proxy here) uses in the SATO P2P system currently only
the user part of the SIP URI for the registration process. The P2P
SIP registrar stores the given user part of the URI in the DHT
together with its (or one of its) IP addresses. The real location of
the UA is only stored in the P2PSIP registrar.
The entry in the DHT and P2PSIP registrar is deleted, when the user
Stiemerling, et al. Expires April 18, 2007 [Page 6]
Internet-Draft P2PSIP Implementation October 2006
should be deregistered, i.e., either by timeout of the registration
or explicitly request.
4. Running a P2P Call
Placing a call from one UA1 to UA2 (see xref
target="fig.p2psipsato"/>) is again following the possible call flows
in [RFC3261] from UA to P2PSIP overlay peer. The SIP proxy at the
overlay peer receiving the call request (SIP) is using the user part
of the SIP URI for the DHT lookup. If the user is registered in the
DHT, i.e., register at some overlay peer, the IP address of the
serving overlay peer is obtained. Otherwise a 404 (Not Found)
response is generated and send to the UA. This IP address is
transfered from SIP1 to the local overlay manager OM1. OM1 uses the
P2PSIP Overlay Peer Protocol to contact OM2 on the target overlay
peer where UA2 is registered to. OM1 and OM2 negotiate the possible
and by the SIP proxy desired transport connection between SIP1 and
remote P2PSIP proxy SIP2. Once the transport connection between SIP1
and SIP2 is setup, both are notified about this. SIP1 forwards the
SIP messages from UA1 (with modified values of some SIP headers to
reflect the routing) to SIP2 via this transport connection (TCP in
the example). SIP2 in turn forwards the message to UA2. Subsequent
SIP messages are transfered via this transport connection.
+----------+ +----------+
| +------+ | | +------+ |
| | OM1 |#################| OM2 | |
| +------+ | | +------+ |
| | | |
+------+ SIP | +------+ | | +------+ | SIP +------+
| UA1 +-------+ SIP1 *=================* SIP2 +-------+ UA2 |
+--+---+ | +------+ | | +------+ | +--+---+
| | | | | |
| | +------+ | | +------+ | |
+-----------+ RTP1 *=================* RTP2 +----------+
| +------+ | | +------+ |
+----------+ +----------+
---- UDP protocol
==== TCP protocol (or what you have)
#### Webservice via TCP
Figure 2: P2PSIP overlay network
In the process of the call signalling, both P2PSIP proxies (SIP1 and
Stiemerling, et al. Expires April 18, 2007 [Page 7]
Internet-Draft P2PSIP Implementation October 2006
SIP2) will replace the media IP address(es) and port(s) by an IP
address and port of their local RTP proxy. The SDP part of UA1 will
be replaced with IP addresses/ports of RTP2 and of UA2 with IP
addresses/ports of RTP1. This behaviour can turned on or off per
configuration in the respective P2PSIP proxies if the media should
delivered directly between UA1 and UA2. OM1 and OM2 will take care
of setting up the desired transport connection between RTP1 and RTP2.
The example uses TCP but any other transport can used. Now the call
can proceed and when the call ends all transport connections between
SIP1/SIP2 and RTP1/RTP2 are teared down.
5. Conclusions
This memo sketches the Ambient Networks SATO-based peer-to-peer SIP
system, which is one possible way to realize such a P2PSIP system.
It uses a generalized overlay deployment system, a well-known
distributed lookup service and unmodified SIP stacks in proxies and
user agents. Not yet described but also implemented is the lookup of
media/packet relays and their inclusion into the overlay network.
This enables support for NAT/firewall traversal of signalling and
data. The exact changes in the SIP routing and the SIP header values
are not yet listed in this memo, but will be added to the next
revision.
The intention of this document is raise further discussions and not
to give a final recommendation or similar.
6. Security Considerations
To be done.
7. Acknowledgments
Martin Stiemerling and Marcus Brunner are partly funded by Ambient
Networks, a research project supported by the European Commission
under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission.
8. References
Stiemerling, et al. Expires April 18, 2007 [Page 8]
Internet-Draft P2PSIP Implementation October 2006
8.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
8.2. Informative References
[AMBIENT] "IST project 507134 Ambient Networks (AN)", Web
Site http://www.ambient-networks.org, October 2006.
[BAMBOO] "BAMBOO DHT", Web Site http://bamboo-dht.org/,
October 2006.
[I-D.willis-p2psip-concepts]
Willis, D., "Concepts and Terminology for Peer to Peer
SIP", draft-willis-p2psip-concepts-01 (work in progress),
August 2006.
Authors' Addresses
Martin Stiemerling
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de/
Marcus Brunner
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 129
Fax: +49 6221 4342 155
Email: marcus.brunner@netlab.nec.de
URI: http://www.netlab.nec.de/
Stiemerling, et al. Expires April 18, 2007 [Page 9]
Internet-Draft P2PSIP Implementation October 2006
Marco Cassini
University of Turin
Turin
Italy
Stiemerling, et al. Expires April 18, 2007 [Page 10]
Internet-Draft P2PSIP Implementation October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Stiemerling, et al. Expires April 18, 2007 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-26 14:48:25 |