[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/