SPEERMINT Working Group                                        J-F. Mule
Internet-Draft                                                 CableLabs
Expires: December 21, 2006                                 June 19, 2006

       SPEERMINT Requirements for SIP-based VoIP Interconnection

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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

   o  Some requirements SHOULD make use of key words per RFC 2119

   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

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

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

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

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

   Editor's Note:
   RTP media sessions SHOULD also make use of secure RTP - For Futher

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

              Rosenberg, J., "A Hitchhikers Guide to the Session
              Initiation Protocol (SIP)", February 2006.

              Peterson, J. and C. Jennings, "A Hitchhikers Guide to the
              Session Initiation Protocol (SIP)", October 2005.

              Meyer, R., "SPEERMINT Terminology", May 2006.

Author's Address

   Jean-Francois Mule
   858 Coal Creek Circle
   Louisville, CO  80027

   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

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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Mule                    Expires December 21, 2006              [Page 10]