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]