H. Sinnreich/Adobe, editor
A. Johnston/Avaya
E. Shim/Panasonic
K. Singh/Adobe
Internet Draft
Expires: March 2007 October 15, 2006
Lightweight SIP Toolkit for Peer-to-Peer and Basic Client-
Server Systems
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.
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 15, 2007.
Abstract
The number of SIP related standards can be significantly
reduced for various application scenarios by (1) using SIP
Sinnreich et al. Expires March 2007 [Page 1]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
without "network based services" and (2) without emulating the
telephone network.
Such an approach reduces the number of SIP related standards
(as by mid 2006) from roughly 100 to about 11. Core SIP
interoperability and SIP compliance can be preserved without
relying on complex server based networks.
Successful IP communications must also include the relevant
standards for NAT traversal, some of which are not directly
related to SIP and also several standards for security. These
standards are included here as well.
Conventions used in this document
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [1].
Table of Contents
1. Introduction.........................................3
2. Methodology to Develop Lightweight SIP...............4
2.1 Updating the use of SIP and SDP...................5
2.2 Re-using other SIP standards......................6
3. Presence and Instant Messaging.......................6
3.1 Presence............................................6
3.2 Instant Messaging...................................6
4. NAT and Firewall Traversal...........................6
5. Security Considerations..............................7
5.1 Security for SIP Signaling........................7
5.2 Media Security....................................8
5.3 Authenticated Identity for SIP....................8
6. IANA Considerations..................................8
7. Conclusions.......................................8
8. Acknowledgements.....................................8
9. References...........................................9
9.1 Normative References..............................9
9.2 Informative References............................9
Author's Addresses........................................10
Intellectual Property Statement...........................12
Sinnreich et al. Expires March 2007 [Page 2]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
Disclaimer of Validity....................................12
Copyright Statement.......................................12
Acknowledgment............................................13
1. Introduction
SIP standardization was started in the IETF in 1996 in the
expectation to have a simple and flexible protocol for
establishing multimedia communication. In the roughly ten years
that have passed, the SIP family of related protocols has grown
into approximately 100 RFCs with thousands of pages of
specifications [12] and an ever increasing number of Internet
Drafts, many of them about to join and thus increase even more
the large number of existing RFCs on SIP.
The common root of the complexity of SIP is (a) the overuse of
the client server model and the resulting migration of endpoint
applications, such as voice, presence, IM and video into (b)
"network based services" trying to emulate the telephone system.
P2P SIP systems may not need to support many of the network
based services. And by the nature of P2P systems, their
architectural difference from client server systems, P2P SIP
systems may need approaches different from those taken in the
context of client-server (CS) SIP to realize certain services.
The emergence of P2P SIP raises the question as to what parts of
SIP must be used to (1) preserve the core SIP properties, (2)
preserve basic interoperability with server based SIP systems
and (3) preserve the advantages of SIP for use in P2P
communication systems.
The objective of this memo is to clarify what parts of SIP are
essential to meet these objectives. We will refer for brevity in
the following to these essential tools for SIP as "LIGHTWEIGHT
SIP".
This memo is not trying to redefine SIP in any sense.
Also, it is important to note that using the lightweight tools
for SIP is not a profile of SIP. Furthermore it involves no
modifications or subtractions to the MUSTs in RFC3261. And it is
not a subset of the SIP protocol, either. However, it represents
an attempt to reign in the seemingly endless set of SIP
extensions which add "network functionality and services" to the
SIP ecosystem.
Sinnreich et al. Expires March 2007 [Page 3]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
Lightweight SIP separates the SIP discovery and message
routing functions from the other SIP extensions aimed at
providing applications in the network. The notion of basic
CS SIP is understood here as the functions that provide
only endpoint discovery and SIP message routing for session
initiation.
Though Lightweight SIP is targeted primarily for P2P SIP,
Lightweight SIP is also useful for basic CS SIP systems that
use the peer-to-peer SIP call control model [13], not to be
confused with P2P SIP.
Even complex telephony functions can be accomplished with
Lightweight SIP, but with the difference that all the complex
features are endpoint resident. Such applications do not rely
on any other service in the network except registration and
proxy, as specified in RFC 3261. Examples of specialized
telephony applications residing in endpoints are the
interactive voice response (IVR), the auto-attendant, the
receptionist workstation and the agent workstation in a
customer contact center.
Lightweight SIP is therefore limited to the original intent
of SIP; establishing sessions between endpoints and leaving
the applications in the endpoints. Establishing a session
also includes the negotiation of the session parameters.
2. Methodology to Develop Lightweight SIP
The method to develop Lightweight SIP has several parts:
a. Preserve the basic SIP definitions as per RFC 3261 [2].
SIP can work with or without servers. The trapezoid model
in RFC 3261 is only an example. Also, in the trapezoid
model no attempt is made to provide any specific services
in the network, since the proxies only act as application
level message routers. We do not propose any changes to RFC
3261, to eliminate any methods or headers, error messages,
etc., since this would carry among other risks the danger
of losing backward interoperability and lack of
flexibility.
b.
Analyze the main SIP related specifications as
highlighted in [14] and eliminate all network based
services residing in servers and various other network
elements.
Sinnreich et al. Expires March 2007 [Page 4]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
c.
Adopt the NAT traversal techniques developed for SIP.
d.
Adopt the security techniques developed for SIP and RTP,
to the extent that they are not dependent on central
control and on providing network based telephony style
services.
2.1 Updating the use of SIP and SDP
We do not intend to re-write RFC 3261 for Lightweight SIP, but
to take into account later work in SIP. Examples are:
. Add items that have been developed in later work on
SIP, such as the use of "rport" in the Via header and how
to use the connection data "c=" in the SDP body behind a
NAT. This information is now used differently as per RFC
3489bis defining the STUN protocol.
. Add the offer/answer model with SDP as per RFC 3264
[3].
. Add Locating SIP Servers [4].
. Make TLS mandatory and leave S/MIME optional since it
has not found as wide acceptance. Note that not making
S/MIME mandatory does not preclude end-to-end privacy of
messages in P2P SIP. End-to-end privacy is still possible
in the single hop P2P SIP architecture.
. Simplify early media by specifying that User Agents
accept but do not generate early media. Early media
functionality is best delegated to IP-PSTN VoIP gateway
networks.
Most of the User Agent behavior described in RFC 3261 can be
re-used in Lightweight SIP, while the proxy behavior should be
Sinnreich et al. Expires March 2007 [Page 5]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
limited to the most basic interoperability between P2P SIP
nodes and CS SIP systems.
One key difference between RFC 3261 and P2P SIP systems is the
replacement of the location database at the back side of SIP
proxy and registrar servers with the P2P DHT layer as proposed
in [15].
2.2 Re-using other SIP standards
A summary review of the other over roughly 100 SIP related
standards reveals that they are mostly dedicated to telephony
style of "services in the network" and therefore are out of
scope for Lightweight SIP. The only exception is probably RFC
3840 for indicating user agent capabilities [5], such as for
various media types and SIP events.
3. Presence and Instant Messaging
3.1 Presence
Subscriptions and notifications for presence based on SIP have
been defined in [6] and the data format for presence information
has been defined in [7].
Rich presence information can be conveyed about the location,
activity and other data about a user. Presence can also be used
to integrate applications and communications. Such extended
applications for presence are however beyond the scope of this
memo.
3.2 Instant Messaging
Instant messaging for SIP is based on the simple extension
"MESSAGE" defined in [8].
Interesting activity information can be conveyed in various
ways, such as the indication of "is typing" [9].
4. NAT and Firewall Traversal
While NAT traversal is not strictly speaking a SIP signaling
property, we believe that any IP communication and application
is useless without complete NAT traversal capabilities. The
essential documents for a complete solution for NAT traversal
for SIP based communications are referenced here.
Sinnreich et al. Expires March 2007 [Page 6]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
A. Requirements for NAT to "behave" [16] for UDP packets.
B. NAT Traversal for SIP
1. Updating the Via header information with "rport" for
symmetric response routing [10].
2. Connection reuse for "SIP Outbound" [17].
C. NAT Traversal for RTP/RTCP Media
1. Symmetric RTP [11]
2. Simple Traversal Under NAT (STUN) [18]
3. Media relay function for STUN servers [19]
4. Interactive Connectivity Establishment (ICE) [20].
An excellent summary of all the above in the form of deployment
examples is given in the document on NAT scenarios [21].
5. Security Considerations
Security for SIP communications touches on both signaling and
media. Existing security standards for CS SIP are described
here. In P2P SIP systems, besides the security for signaling and
media, the additional security for the P2P layer must also be
provided. There are however no security standards as yet for P2P
SIP.
5.1 Security for SIP Signaling
SIP secure authentication between the UA and the server is based
on the digest authentication schema as specified in RFC 3261.
SIP transport security for confidentiality is based on Transport
Level Security (TLS) that is also specified in RFC 3261.
End-to-end SIP security through intermediaries based on S/MIME
has not found wide application at present, but it MAY be
implemented in Lightweight SIP. Instead, P2P TLS connections
SHOULD be used to achieve end-to-end security.
Sinnreich et al. Expires March 2007 [Page 7]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
5.2 Media Security
End-to-end media security without any dependency on
intermediaries, such as SIP proxies and certificate authorities
will be provided using SRTP as per RFC 3711.
Key management for SRTP is currently an active area of
discussion and standardization in the IETF.
The authors favor key management approaches that have no
reliance on centralized certificate authorities and PKI
infrastructures. For VoIP, the recommended protocol is ZRTP
protocol [22]. ZRTP is based on users authenticating themselves
to each other by voice or video, before activating media
encryption for the rest of the conversation and for all
following communications.
5.3 Authenticated Identity for SIP
In scenarios where the identity and authentication is required,
the SIP identity header will be used as described in [23]. In
P2P systems, the user enrollment server can be the source for
the authentication service.
6. IANA Considerations
There are no IANA considerations associated with this memo.
7. Conclusions
We have shown in this document how the number of SIP related
standards for presence, IM and multimedia communications can be
reduced by (1) using SIP without network based services and (2)
without emulating the telephone network. The approach for
Lightweight SIP reduces the number of SIP related standards (as
in 2006) from roughly 100 to about 11. Successful IP
communications must however include a number of standards for
NAT traversal, some of which are not directly related to SIP.
The standards for NAT traversal are however referenced here,
since SIP based communications must traverse NAT.
8. Acknowledgements
We would like to thank Wilhelm Wimmreuter for the detailed
review of the initial draft.
Sinnreich et al. Expires March 2007 [Page 8]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
9. References
9.1 Normative References
[1] RFC 2119: "Key words for use in RFCs to Indicate Requirement
Levels" by S. Bradner. IETF, March 1997.
[2] RFC 3261: "SIP: Session Initiation Protocol" by J. Rosenberg
et al. IETF June 2002.
[3] RFC 3264: "An Offer/Answer Model with Session Description
Protocol (SDP)" by J. Rosenberg and H. Schulzrinne. June 2002.
[4] RFC 3263 "Locating SIP Servers" by J. Rosenberg and H.
Schulzrinne. IETF, June 2002.
[5] RFC 3840: "Indicating User Agent Capabilities in SIP" by J.
Rosenberg, et al. IETF, August 2004.
[6] RFC 3856: "A Presence Event Package for SIP" by J.
Rosenberg. IETF, August 2004.
[7] RFC 3863 "Presence Information Data Format (PIDF)" by H.
Sugano et al. IETF, August 2004.
[8] RFC 3428: "SIP Extension for Instant Messaging" by B.
Campbell et al. IETF, December 2002.
[9] RFC 3994: "Indication of Message Composition for Instant
Messaging" by H. Schulzrinne. IETF, January 2005.
[10] RFC 3581: "An Extension to SIP for Symmetric Response
Routing" by J. Rosenberg and H. Schulzrinne. IETF, August 2003.
[11] RFC xxxx: "Symmetric RTP and RTCP Considered Helpful" by D.
Wing. IETF, 2006.
9.2 Informative References
[12] "VoIP RFC Watch" by Nils Ohlmeier, http://rfc3261.net/.
[13] "A Call Control and Multi-party usage framework for SIP" by
R. Mahy et al. <draft-ietf-sipping-cc-framework-06.txt>. Work in
progress, IETF, March 2006.
Sinnreich et al. Expires March 2007 [Page 9]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
[14] "A Hitchikers' Guide to SIP" by J. Rosenberg. <draft-
rosenberg-sip-hitchhikers-guide>. Work in progress, IETF,
February 2006.
[15] "SIP, P2P and internet Communications" by A. Johnston and
H. Sinnreich. Work in progress, Internet Draft, IETF, March
2006.
[16] "NAT Behavioral Requirements for Unicast UDP" by F. Audet
and C. Jennings. Work in progress, <draft-ietf-behave-nat-udp>,
IETF, May 2006.
[17] "Managing Client Initiated Connections in SIP" by C.
Jennings and R. Mahy. Work in progress, < draft-ietf-sip-
outbound>, IETF, June 2006.
[18] RFC 3489bis: "Simple Traversal Under NAT (STUN)" by J.
Rosenberg et al. Work in progress, < draft-ietf-behave-
rfc3489bis> , IETF, July 2006.
[19] "Obtaining Relay Addresses from Simple Traversal of UDP
Through NAT (STUN)" by J. Rosenberg, <draft-ietf-behave-turn>.
Work in progress, IETF, February 2006.
[20] "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols" by J.Rosenberg. Work in progress,
<draft-ietf-mmusic-ice>, IETF, August 2006.
[21] "Best Current Practices for NAT Traversal for SIP" by C.
Boulton et al. Work in progress, < draft-ietf-sipping-nat-
scenarios>, IETF, June 2006.
[22] "ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement
for SRTP" by P. Zimmermann et al. Work in progress, IETF, March
2006.
[23] "Enhancements for Authenticated Identity Management in SIP"
by J. Peterson and C. Jennings, <draft-ietf-sip-identity>. Work
in progress, IETF, October 2005.
Author's Addresses
Alan Johnston
Avaya
Sinnreich et al. Expires March 2007 [Page 10]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
211 Mt. Airy Rd.
Basking Ridge, NJ 07920
USA
Email: alan.b.johnston@avaya.com
Eunsoo Shim
Panasonic Princeton Laboratory
Two Research Way, 3rd Floor
Princeton, NJ 08540, USA
Email: eunsoo@research.panasonic.com
Kundan Singh
Adobe Systems, Inc.
601 Townsend Street,
San Francisco, CA 94103, USA
Email: kundan@adobe.com
Henry Sinnreich
Adobe Systems, Inc.
601 Townsend Street,
San Francisco, CA 94103, USA
Email: henrys@adobe.com
Sinnreich et al. Expires March 2007 [Page 11]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
Intellectual Property Statement
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. By submitting
this Internet-Draft, I certify that any applicable patent or
other IPR claims of which I am aware have been disclosed, and
any of which I become aware will be disclosed, in accordance
with RFC 3668.
Disclaimer of Validity
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.
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.
Sinnreich et al. Expires March 2007 [Page 12]
Internet-Draft draft-sinnreich-sip-tools-00.txt March 2007
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sinnreich et al. Expires March 2007 [Page 13]
