SPEERMINT Working Group J-F. Mule
Internet-Draft CableLabs
Expires: December 21, 2006 June 19, 2006
SPEERMINT Requirements for SIP-based VoIP Interconnection
draft-ietf-speermint-requirements-00.txt
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes general requirements for Session PEERing for
Multimedia INTerconnect and defines the minimum set of requirements
applicable to SIP session peering for VoIP interconnects.
In its current form, the document is a first draft based on the
SPEERMINT mailing list's discussions on requirements. The main
objectives are to generate consensus on what categories of
requirements should be covered, and to start more discussions on the
technical protocol requirements that apply to VoIP interconnects.
Mule Expires December 21, 2006 [Page 1]
Internet-Draft SPEERMINT Requirements June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Requirements . . . . . . . . . . . . . . . . . . . . . 3
2.1. Unified solution for session peering policies . . . . . . . 3
2.2. Domain Based . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. No blocked calls . . . . . . . . . . . . . . . . . . . . . 4
2.4. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Independence of lower layers . . . . . . . . . . . . . . . 4
2.6. Administrative and technical policies . . . . . . . . . . . 4
2.7. Minimal additional cost on call initiation . . . . . . . . 5
2.8. Look beyond SIP . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements for SIP-based VoIP Interconnection . . . . . . . . 5
3.1. DNS, Call Routing Data (CRD) and ENUM . . . . . . . . . . . 5
3.2. Minimum set of SIP-SDP-related requirements . . . . . . . . 6
3.3. Media-related requirements . . . . . . . . . . . . . . . . 6
3.4. Security requirements . . . . . . . . . . . . . . . . . . . 7
4. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Mule Expires December 21, 2006 [Page 2]
Internet-Draft SPEERMINT Requirements June 2006
1. Introduction
The Session PEERing for Multimedia INTerconnect (SPEERMINT) Working
Group is chartered to focus on architectures to identify, signal, and
route delay-sensitive communication sessions. These sessions use the
SIP signaling protocol to enable peering between two or more
administrative domains over IP networks.
This document describes general SPEERMINT requirements for session
peering and defines the minimum set of requirements for SIP-based
VoIP interconnection. A number of Editor's Notes have been inserted
in the text to seek specific comments on draft requirements.
The reader should be familiar with the definitions and terms defined
in the SPEERMINT terminology draft [SPEERMINT-TERM].
2. General Requirements
The following section defines general requirements applicable to the
"solution space".
Editor's Notes:
o this section will capture the general requirements per wg
consensus.
o Some requirements SHOULD make use of key words per RFC 2119
[RFC2119].
o Most of the requirements contained in this version of the draft
are derived from draft-ietf-speermint-reqs-and-terminology-01.txt.
o Some requirements apply to entities performing session peering
while others apply to end-systems. Some statements seem to be
"design goals" for the working group to consider when discussing
solutions.
2.1. Unified solution for session peering policies
Policies developed in the context of the SPEERMINT working group
SHOULD be extensible and flexible enough to cover existing and future
peering policies. These start by a closed system which accepts only
incoming calls from selected peers (i.e. a set of bilateral peerings)
and include the model of membership in a number of peering fabrics or
carrier clubs. The case of an open SIP proxy should be covered as a
special case as well.
Mule Expires December 21, 2006 [Page 3]
Internet-Draft SPEERMINT Requirements June 2006
2.2. Domain Based
Although the initial call routing may be based on E.164 numbers, a
generic peering methodology should not rely on such numbers. Rather,
call routing should rely on URIs. We assume that all SIP URIs with
the same domain-part share the same set of peering policies, thus the
domain of the SIP URI may be used as the primary key to any
information regarding the reachability of that SIP URI.
2.3. No blocked calls
An originating service provider must be able to determine whether a
SIP URI is open for direct interconnection without actually sending a
SIP INVITE. This is important as unsuccessful call attempts are
highly undesirable since they can introduce high delays due to
timeouts and can act as an unintended denial of service attack.
(e.g., by repeated TLS handshakes).
2.4. Scaling
The maintenance of the system needs to scale beyond simple lists of
peering partners. In particular, it must incorporate aggregation
mechanisms which avoid O(n^2) scaling (where n is the number of
participating service providers). Per-service provider opt-in
without consultation of a centralized 'peering registry', but rather
by publishing local configuration choices only is highly desirable.
The distributed management of the DNS is a good example for the
scalability of this approach.
2.5. Independence of lower layers
The system needs to be independent of details on what technologies
are used route the call and which are used to ensure that only
approved peering partner actually connect to the destination SIP
proxy. It should not matter whether restrictions are implemented by
private L3 connectivity ("walled gardens"), firewalls, TLS policies
or SIP proxy configuration.
2.6. Administrative and technical policies
The reasons for declining vs. accepting incoming calls from a
prospective peering partner can be both administrative (contractual,
legal, commercial, or business decisions) and technical (certain QoS
parameters, TLS keys, domain keys, ...). Methodologies developed by
the SPEERMINT working group should accommodate all policies.
Mule Expires December 21, 2006 [Page 4]
Internet-Draft SPEERMINT Requirements June 2006
2.7. Minimal additional cost on call initiation
Since each call setup implies execution of any proposed algorithm, it
should incur minimal overhead and delay, and employ caching wherever
possible to avoid extra protocol round trips.
2.8. Look beyond SIP
The problem of selective peering is not limited to SIP-based
communication. Other protocols may benefit from a generic framework
as well, such as SMTP mail. Any solutions proposed by the SPEERMINT
working group must be generic enough to encompass other protocols as
well.
3. Requirements for SIP-based VoIP Interconnection
This section defines some requirements for SIP-based VoIP
Interconnection. It should be considered as the minimal set of
recommendations or requirements to be met to perform SIP VoIP
interconnects.
3.1. DNS, Call Routing Data (CRD) and ENUM
Call Routing Data can be derived from ENUM or other mechanism
available to the user. While the SPEERMINT Working Group is focused
on the use of CRD, a number of recommendations are captured here.
Editor's Note:
After reviewing the mailing list threads, it seems that some folks
suggest some pointers to ENUM. Do any requirements belong here
because they would 'facilitate' the VoIP interconnects?
o SIP URIs SHOULD be preferred when establishing a SIP session.
o The recommendations defined in [RFC3824] SHOULD be followed for
using E.164 numbers with SIP.
o The use of DNS domain names and hostnames is RECOMMENDED in SIP
URIs and they MUST be resolvable on the public Internet.
o The DNS procedures specified in [RFC3263] SHOULD be followed to
resolve a SIP URI into a reachable host (IP address and port), and
transport protocol. Note that RFC 3263 relies on DNS SRV
[RFC2782] and NAPTR Resource Records [RFC2915].
o Editor's Note:
For BCP and for the sake of discussions, some service providers or
Mule Expires December 21, 2006 [Page 5]
Internet-Draft SPEERMINT Requirements June 2006
enterprises skip the dynamic determination of the transport
protocol in 3263 (this is very often statically configured and it
is viewed as costly to do on a per URI basis) and they only use
SRV RRs for finding the target.
The implications of RFC3263 are NAPTR and SRV RRs must be
supported on the DNS clients of the systems facing the session
peering interconnect points: should we make these types of
requirements more visible in this document as attempted above?
o Editor's Note:
While the use of User or Carrier ENUM to resolve an E.164 address
into a set of URIs is generally considered out of scope of
SPEERMINT and this document, should this section contain a few
recommendations like the use of RFC 3824 per the aboce, or the
Enumservice types that SHOULD be supported and requested when
doing lookups for SIP-based VoIP interconnect as a few email
exchanges have shown? for e.g. E2U+sip per RFC 3764? what about
recommendations w.r.t. RFC 4415 and the handling or use of "E2U+
voice:tel" or does the above suffice?
3.2. Minimum set of SIP-SDP-related requirements
The following are session-related requirements for establishing SIP
sessions for VoIP interconnections:
o The Core SIP Specifications as defined in [RFC3261] and
[SIP-GUIDE] MUST be supported by any SIP implementations involved
in SPEERMINT session peering.
o In addition, the following RFCs MUST be supported: the Session
Description Protocol (SDP) [RFC2327], and the Offer/Answer
mechanism with SDP [RFC3264].
o The following RFCs SHOULD be supported: Reliability of Provisional
Responses in SIP - PRACK [RFC3262], the SIP UPDATE method (for
e.g. for codec changes during a session) [RFC3311], the Reason
header field [RFC3326].
The recommendations contained in RFC 3261 regarding the use of the
Supported and Require headers MUST be followed: any SIP entity
involved in session peering SHOULD include the supported SIP
extensions in the Supported header and the use of the Require header
must be flexbile to maximize interoperability.
3.3. Media-related requirements
The minimum requirements to allow a successful VoIP interconnection
include:
Mule Expires December 21, 2006 [Page 6]
Internet-Draft SPEERMINT Requirements June 2006
o the mandatory support of RTP *and* RTCP as defined in [RFC3550],
o the support of compatible codecs between communication peers, the
G.711 MUST be supported, the IETF iLBC [RFC3951] codec and its RTP
payload format [RFC3952] SHOULD be supported.
o the support of the VoIP metric block as defined in RTP Control
Protocol Extended Reports [RFC3611] MAY be supported.
Editor's Notes:
o Should the minimum set of requirements for VoIP interconnect
include any media-related requirements at all?
o The speerming charter defines "VoIP" as in voice calls. Does
voice communication mean audio only or more? audio, DTMF tones,
real-time fax, voiceband data?
3.4. Security requirements
All SIP messages MUST be sent over TLS [RFC3546] to provide
transport-layer security as defined in RFC 3261, at a minimum to
provide message authentication and based on the mechanisms defined in
SIP Identity [SIP-IDENTITY]to identify the peer originating SIP
messages.
Editor's Note:
RTP media sessions SHOULD also make use of secure RTP - For Futher
Study.
4. Open Questions
This section documents some of the open questions not resolved yet on
the wg mailing list.
5. Acknowledgments
This document is based on the input and contributions made by a large
number of people in SPEERMINT , including: Scott Brim, Mike Hammer,
Richard Shocky, Henry Sinnreich, Richard Stastny, Patrik Faltstrom,
Otmar Lendl, Dave Meyer, Jason Livingood, Bob Natale and Brian Rosen.
6. Security Considerations
This requirement document itself introduces no new protocol
Mule Expires December 21, 2006 [Page 7]
Internet-Draft SPEERMINT Requirements June 2006
mechanisms, and as such, no new security considerations. A number of
security requirements are described in a separate section.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
Mule Expires December 21, 2006 [Page 8]
Internet-Draft SPEERMINT Requirements June 2006
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using
E.164 numbers with the Session Initiation Protocol (SIP)",
RFC 3824, June 2004.
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn,
W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)",
RFC 3951, December 2004.
[RFC3952] Duric, A. and S. Andersen, "Real-time Transport Protocol
(RTP) Payload Format for internet Low Bit Rate Codec
(iLBC) Speech", RFC 3952, December 2004.
7.2. Informative References
[SIP-GUIDE]
Rosenberg, J., "A Hitchhikers Guide to the Session
Initiation Protocol (SIP)", February 2006.
[SIP-IDENTITY]
Peterson, J. and C. Jennings, "A Hitchhikers Guide to the
Session Initiation Protocol (SIP)", October 2005.
[SPEERMINT-TERM]
Meyer, R., "SPEERMINT Terminology", May 2006.
Author's Address
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: jfm@cablelabs.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Mule Expires December 21, 2006 [Page 9]
Internet-Draft SPEERMINT Requirements June 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 currently provided by the
Internet Society.
Mule Expires December 21, 2006 [Page 10]
