SPEERMINT A. Newton Internet-Draft SunRocket, Inc. Intended status: Informational August 25, 2006 Expires: February 26, 2007 An ITSP Problem Statement Regarding SIP Peering draft-newton-speermint-itsp-problem-statement-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. 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 February 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Newton Expires February 26, 2007 [Page 1] Internet-Draft itsp-problem August 2006 Abstract This document illustrates the operational considerations of Internet Telephony Service Providers (ITSP) with regard to SIP peering. Newton Expires February 26, 2007 [Page 2] Internet-Draft itsp-problem August 2006 1. Introduction and Background This document illustrates operational considerations of an Internet Telephony Service Provider (ITSP) with regard to SIP [1] peering. These considerations focus on the technical requirements needed to establish and operate SIP peering. While such functions as settlement of payment and the transmission of call detail records do have technical components, such subjects are out of scope of this document. The goal of this document is to define the operational considerations of an ITSP for the creation and formalization of requirements from which specifications may be written. 1.1. Terminology This document attempts to use the terminology defined by draft-ietf-speermint-terminology [2]. In addition, this document defines the additional term: o Routed Peering - refers to the use of directories or SIP redirect proxies to act as a routing function which facilitates direct peering, indirect peering, or assisted peering. As explained in Section 1.3, not all peer networks offering Indirect Peering, or transit, are capable of terminating all calls. Therefore, the following term is defined: o Limited Indirect Peering - refers to the inability to offer indirect peering, or transit, for all calls. 1.2. Peering Relationships Relationships with other SIP networks occur into two fashions: bi- lateral relationships and multi-lateral relationships. With bi-lateral relationships, an ITSP has a specific relationship with another, single SIP network. This relationship is managed directly and explicitly by the ITSP and the partner SIP network, and constitutes Direct Peering. An ITSP typically has many bi-lateral agreements. Multi-lateral peering allows an ITSP to peer with many other SIP networks while managing a single relationship with a coordinating entity. Unlike bi-lateral peering, multi-lateral peering takes many forms. A multi-lateral peering relationship may occur using a combination of Direct Peering, Indirect Peering, Assisted Peering, and Routed Peering combined with either Layer 3 Peering or Layer 5 Newton Expires February 26, 2007 [Page 3] Internet-Draft itsp-problem August 2006 Peering. The marketplace for entities offering multi-lateral relationships is changing rapidly. A few years ago, most of these entities did not offer such arrangements over SIP. Today, most of these entities offer multi-lateral relationships only for Indirect Peering, or transit. However, the marketplace is changing rapidly, and their are now many entities coordinating multi-lateral relationships for the purpose of facilitating Direct Peering. 1.3. Call Termination When a call originates from an ITSPs network, the ITSP must decide where to terminate the call. There are three choices: For subscriber to subscriber calls, the ITSP may terminate the call on its own network. This is typically referred to as on- network (or on-net) termination. For subscriber to non-subscriber calls, the ITSP may terminate the call with one of the SIP networks with which it has a peering relationship. This is typically referred to as off-network (or off-net) termination. For subscriber to non-subscriber calls, the ITSP also has the option to terminate the call via a gateway to another network, typically the Public Switched Telephone Network or PSTN. This is also referred to as off-network termination. For off-network termination, it is quite common to be able to terminate a given call with multiple peers. In these cases, an ITSP picks the peer network for which to terminate the call according to specific business logic, usually based on pricing. Traditionally, transit providers and entities offering Indirect Peering are able to terminate any call given to them, especially within the E.164 [5] namespace. However, due to the changing marketplace, this is no longer a given. When an ITSP must perform off-network termination, it must also understand which of its peer networks have the ability to terminate the call, not just which peer network might cost the least to terminate the call. This impacts the logic used by an ITSP to have default peering routes. Newton Expires February 26, 2007 [Page 4] Internet-Draft itsp-problem August 2006 2. Namespace Management SIP operates naturally with two namespaces, IP addresses and domain names. Traditionally, telephony uses the E.164 [5] namespace. Most ITSPs, though not all, must deal with all three namespaces. Because IP addresses and domain names are natural to SIP, they require no more management with regard to the operation of SIP than other modern day Internet applications. This is not true for E.164. Use of the E.164 namespace is most commonly accomplished with ENUM. However, there are other mechanisms, such as DUNDI or SIP redirects. 2.1. Provisioning When using E.164 numbers and Indirect Peering, there is usually a need for the Indirect Peering, or transit, providers to receive from an ITSP the list of E.164 numbers that may be terminated by that ITSP. This process is often called provisioning. Each Indirect Peering provider uses a different method for provisioning, requiring an ITSP to incorporate a separate method within its operational practices for each provider with which it has an Indirect Peering relationship. It should be noted that RFC 4114 [3] does provide a standard for provisioning. 2.2. Number Lookup For Direct Peering and Limited Indirect Peering, an ITSP must first determine if the peer network has the capability to terminate the call. When using E.164 numbers, this requires a number lookup into a database. There are multiple methods for doing this lookup, such as ENUM [4] or DUNDI. Some peering relationships allow an ITSP to send SIP invites and receive redirects or rejects to accomplish this goal. With many Direct Peering and Limited Indirect Peering relationships, this can become a time consuming task for an ITSP. As an example, if an ITSP has three Direct Peering relationships, it must send an ENUM query to each peer network. Done serially, this could add significant delay when setting up a call. An obvious solution is to send all queries in parallel, but this is still less than ideal. Additionally, because ENUM is a DNS solution and many underlying DNS libraries have 30 second timeouts, some simple failure scenarios such as packet loss can cause unacceptable delay. Newton Expires February 26, 2007 [Page 5] Internet-Draft itsp-problem August 2006 3. Troubleshooting As with any network operation, there needs to be coordination between peering networks to resolve operational issues. When networks are peered as a result of a contract, the operators of the networks exchange points of contact to resolve operational issues. With Indirect Peering, or transit, where a peer network operates a Back- to-Back User Agent or gateways to another type of telephony network, there must always be a point of contact with the indirect peer. However, operational problems with Routed Peering may be resolved more quickly by utilizing a point of contact with the terminating peer network in addition to or instead of utilizing a point of contact with the entity providing the routing function. Standards or best practices around the establishment of points of contact would allow faster resolution of operational problems. Additionally, best practices regarding caller identity and originating provider identity would greatly aid troubleshooting. Newton Expires February 26, 2007 [Page 6] Internet-Draft itsp-problem August 2006 4. Security At present, peering relationships are a matter of contract and require negotiation. They do not occur out of the simple desire to terminate a call with any network. As such, each relationship spells out the security needed to conduct the peering. In many cases, the SIP networks are peered at the link layer or using packet tunneling techniques. This is often done to ensure quality as well as security. These interconnections protect the telephony media as well as the signaling. Because the Internet has many mischievous communities, a SIP network offering more opportunistic peering to the broader Internet population would need to offer security equivalent or better to that which can be found with private arrangements. Simply protecting the signaling is not enough; telephony media must also be protected. Additionally, reputation mechanisms, semantics, and best practices would be required as Internet identities can be acquired cheaply. Newton Expires February 26, 2007 [Page 7] Internet-Draft itsp-problem August 2006 5. Codecs With SIP communications in its infancy, today's ITSP is primarily concerned with audio codecs. As such, the discussion in this section is limited to audio codecs. The minimum set of codecs to support for peering varies widely between peering networks, resulting in a lowest common denominator of the G.711 codecs for wired, broadband voice services. This situation is not desirable to most providers, and an established best practice regarding a minimum set of supported codecs would be desirable. It would be ideal if this codec set had the following characteristics: o Transcoding is not required to peer with the Public Switched Telephone Network. o Transcoding is not required between peer networks supporting the codec list. o Low or no royalty payments are required of vendors or service providers. o Voice quality better than that found on the Public Switched Telephone Network can be accommodated. o Latency and packet loss can be accommodated. Newton Expires February 26, 2007 [Page 8] Internet-Draft itsp-problem August 2006 6. Compliance In relative terms, SIP network peering is in infancy and is rapidly growing. Unfortunately, the number of SIP specifications is also growing, making it difficult for both service providers and vendors to know which specifications are truly deserving of their limited resources and attention. Often times vendors and service providers must guess at which SIP specifications require implementation. Any specification or best practice regarding SIP network peering that does not have a true, current operational need or viable, widespread potential use compounds this confusion and causes harm. Newton Expires February 26, 2007 [Page 9] Internet-Draft itsp-problem August 2006 7. Acknowledgements Joel Rosenfield reviewed and contributed to the content of this draft. Newton Expires February 26, 2007 [Page 10] Internet-Draft itsp-problem August 2006 8. Informative [1] 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. [2] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-terminology-04 (work in progress), August 2006. [3] Hollenbeck, S., "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4114, June 2005. [4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [5] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 1991. Newton Expires February 26, 2007 [Page 11] Internet-Draft itsp-problem August 2006 Author's Address Andrew L. Newton SunRocket, Inc. 8045 Leesburg Pike, Suite 300 Vieanna, VA 22182 USA Email: andy@hxr.us URI: http://www.sunrocket.com Newton Expires February 26, 2007 [Page 12] Internet-Draft itsp-problem August 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). Newton Expires February 26, 2007 [Page 13]