doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc6405.txt b/doc/rfc/rfc6405.txt
new file mode 100644
index 0000000..9156091
--- /dev/null
+++ b/doc/rfc/rfc6405.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    A. Uzelac, Ed.
+Request for Comments: 6405                               Global Crossing
+Category: Informational                                      Y. Lee, Ed.
+ISSN: 2070-1721                                            Comcast Cable
+                                                           November 2011
+
+
+               Voice over IP (VoIP) SIP Peering Use Cases
+
+Abstract
+
+   This document depicts many common Voice over IP (VoIP) use cases for
+   Session Initiation Protocol (SIP) peering.  These use cases are
+   categorized into static and on-demand, and then further sub-
+   categorized into direct and indirect.  These use cases are not an
+   exhaustive set, but rather the most common use cases deployed today.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6405.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 1]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Reference Architecture ..........................................3
+   4. Contexts of Use Cases ...........................................4
+   5. Use Cases .......................................................4
+      5.1. Static Peering Use Cases ...................................5
+      5.2. Static Direct Peering Use Case .............................5
+           5.2.1. Administrative Characteristics .....................10
+           5.2.2. Options and Nuances ................................10
+      5.3. Static Direct Peering Use Case - Assisting LUF and LRF ....11
+           5.3.1. Administrative Characteristics .....................12
+           5.3.2. Options and Nuances ................................12
+      5.4. Static Indirect Peering Use Case - Assisting LUF and LRF ..12
+           5.4.1. Administrative Characteristics .....................19
+           5.4.2. Options and Nuances ................................19
+      5.5. Static Indirect Peering Use Case ..........................19
+           5.5.1. Administrative Characteristics .....................20
+           5.5.2. Options and Nuances ................................21
+      5.6. On-Demand Peering Use Case ................................21
+           5.6.1. Administrative Characteristics .....................21
+           5.6.2. Options and Nuances ................................21
+   6. Acknowledgments ................................................22
+   7. Security Considerations ........................................22
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................23
+
+1.  Introduction
+
+   This document describes important Voice over IP (VoIP) use cases for
+   SIP-based [RFC3261] peering.  These use cases are determined by the
+   Session PEERing for Multimedia INTerconnect (SPEERMINT) working group
+   and will assist in identifying requirements and other issues to be
+   considered for future resolution by the working group.
+
+   Only use cases related to VoIP are considered in this document.
+   Other real-time SIP communications use cases, like Instant Messaging
+   (IM), video chat, and presence are out of scope for this document.
+
+   The use cases contained in this document are described as
+   comprehensive as possible, but should not be considered the exclusive
+   set of use cases.
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 2]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+2.  Terminology
+
+   This document uses terms defined in [RFC5486].  Please refer to it
+   for definitions.
+
+3.  Reference Architecture
+
+   The diagram below provides the reader with a context for the VoIP use
+   cases in this document.  Terms such as SIP Service Provider (SSP),
+   Lookup Function (LUF), Location Routing Function (LRF), Signaling
+   Path Border Element (SBE), and Data Path Border Element (DBE) are
+   defined in [RFC5486].
+
+   The Originating SSP (O-SSP) is the SSP originating a SIP request.
+   The Terminating SSP (T-SSP) is the SSP terminating the SIP request
+   originating from the O-SSP.  The assisting LUF and LRF Provider offer
+   LUF and LRF services to the O-SSP.  The Indirect SSP (I-SSP) is the
+   SSP providing indirect peering service(s) to the O-SSP to connect to
+   the T-SSP.
+
+    +--------------------+------------------------+--------------------+
+    |  Originating SSP   |  Assisting LUF and LRF |  Terminating SSP   |
+    |     Domain         |    Provider Domain     |      Domain        |
+    |                    |                        |                    |
+    |  +-----+  +-----+  |    +------+ +------+   |  +-----+  +-----+  |
+    |  |O-LUF|  |O-LRF|  |    |A-LUF | | A-LRF|   |  |T-LUF|  |T-LRF|  |
+    |  +-----+  +-----+  |    +------+ +------+   |  +-----+  +-----+  |
+    |                    |                        |                    |
+    | +-------+ +-----+  +------------------------+  +-----+ +-------+ |
+    | |O-Proxy| |O-SBE|  |  Indirect SSP Domain   |  |T-SBE| |T-Proxy| |
+    | +-------+ +-----+  |                        |  +-----+ +-------+ |
+    |                    |    +-----+  +-----+    |                    |
+    |    +---+  +-----+  |    |O-SBE|  |O-DBE|    |  +-----+  +---+    |
+    |    |UAC|  |O-DBE|  |    +-----+  +-----+    |  |T-DBE|  |UAS|    |
+    |    +---+  +-----+  |                        |  +-----+  +---+    |
+    |                    |                        |                    |
+    +--------------------+------------------------+--------------------+
+
+                             General Overview
+
+                                 Figure 1
+
+   Note that some elements included in Figure 1 are optional.
+
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 3]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+4.  Contexts of Use Cases
+
+   Use cases are sorted into two general groups: static and on-demand
+   peering [RFC5486].  Each group can be further sub-divided into Direct
+   Peering and Indirect Peering [RFC5486].  Although there may be some
+   overlap among the use cases in these categories, there are different
+   requirements between the scenarios.  Each use case must specify a
+   basic set of required operations to be performed by each SSP when
+   peering.
+
+   These can include:
+
+   o  Peer Discovery - Peer discovery via a Lookup Function (LUF) to
+      determine the Session Establishment Data (SED) [RFC5486] of the
+      request.  In VoIP use cases, a request normally contains a phone
+      number.  The O-SSP will input the phone number to the LUF and the
+      LUF will normally return a SIP address of record (AOR) [RFC3261]
+      that contains a domain name.
+
+   o  Next-Hop Routing Determination - Resolving the SED information is
+      necessary to route the request to the T-SSP.  The LRF is used for
+      this determination.  After obtaining the SED, the O-SSP may use
+      the standard procedure defined in [RFC3263] to discover the next-
+      hop address.
+
+   o  Call setup - SSPs that are interconnecting to one another may also
+      define specifics on what peering policies need to be used when
+      contacting the next hop in order to a) reach the next hop at all
+      and b) prove that the sender is a legitimate peering partner.
+      Examples: hard-code transport (TCP/UDP/TLS), non-standard port
+      number, specific source IP address (e.g., in a private Layer 3
+      network), which TLS client certificate [RFC5246] to use, and other
+      authentication schemes.
+
+   o  Call reception - This step ensures that the type of relationship
+      (static or on-demand, indirect or direct) is understood and
+      acceptable.  For example, the receiving SBE needs to determine
+      whether the INVITE it received really came from a trusted member.
+
+5.  Use Cases
+
+   Please note there are intra-domain message flows within the use cases
+   to serve as supporting background information.  Only inter-domain
+   communications are germane to this document.
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 4]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+5.1.  Static Peering Use Cases
+
+   Static peering [RFC5486] describes the use case when two SSPs form a
+   peering relationship with some form of association established prior
+   to the exchange of traffic.  Pre-association is a prerequisite to
+   static peering.  Static peering is used in cases when two peers want
+   a consistent and tightly controlled approach to peering.  In this
+   scenario, a number of variables, such as an identification method
+   (remote proxy IP address) and Quality-of-Service (QoS) parameters,
+   can be defined upfront and known by each SSP prior to peering.
+
+5.2.  Static Direct Peering Use Case
+
+   This is the simplest form of a peering use case.  Two SSPs negotiate
+   and agree to establish a SIP peering relationship.  The peer
+   connection is statically configured and the peer SSPs are directly
+   connected.  The peers may exchange interconnection parameters such as
+   Differentiated Service Code Point (DSCP) [RFC2474] policies, the
+   maximum number of requests per second, and proxy location prior to
+   establishing the interconnection.  Typically, the T-SSP only accepts
+   traffic originating directly from the trusted peer.
+
+         +--------------------+             +---------------------+
+         |        O-SSP       |             |        T-SSP        |
+         |       +-----+      |             |       +-----+       |
+         |       |O-LUF|      |             |       |T-LUF|       |
+         |       |O-LRF|      |             |      /|T-LRF|       |
+         |      /+-----+\     |             |     / +-----+       |
+         |    (2)     (4,5,6) |             |    /                |
+         |    /           \   |             |   /(8,9)            |
+         |+-------+     +-----+             +-----+      +-------+|
+         ||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
+         |+-------+     +-----+             +-----+      +-------+|
+         |    |               |             |                |    |
+         |   (1)              |             |               (11)  |
+         |    |               |             |                |    |
+         | +-----+      +-----+             +-----+       +-----+ |
+         | | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | |
+         | +-----+      +-----+             +-----+       +-----+ |
+         +--------------------+             +---------------------+
+              example.com                         example.net
+
+
+                      Static Direct Peering Use Case
+
+                                 Figure 2
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 5]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   The following is a high-level depiction of the use case:
+
+   1.   The User Agent Client (UAC) initiates a call via SIP INVITE to
+        O-Proxy.  O-Proxy is the home proxy for UAC.
+
+         INVITE sip:+19175550100@example.com;user=phone SIP/2.0
+         Via: SIP/2.0/TCP client.example.com:5060
+           ;branch=z9hG4bK74bf9
+         Max-Forwards: 10
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=12345
+         To: Bob <sip:+19175550100@example.com;user=phone>
+         Call-ID: abcde
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@client.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   Note that UAC inserted its Fully Qualified Domain Name (FQDN) in the
+   VIA and CONTACT headers.  This example assumes that UAC has its own
+   FQDN.
+
+   2.   UAC knows the User Agent Server's (UAS's) TN, but does not know
+        UAS's domain.  It appends its own domain to generate the SIP URI
+        in the Request-URI and TO header.  O-Proxy checks the Request-
+        URI and discovers that the Request-URI contains the user
+        parameter "user=phone".  This parameter signifies that the
+        Request-URI is a phone number.  So O-Proxy will extract the TN
+        from the Request-URI and query the LUF for SED information from
+        a routing database.  In this example, the LUF is an ENUM
+        [RFC6116] database.  The ENUM entry looks similar to this:
+
+          $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
+          IN NAPTR (
+            10
+            100
+            "u"
+            "E2U+SIP"
+            "!^.*$!sip:+19175550100@example.net!"
+            . )
+
+   This SED data can be provisioned by O-SSP or populated by the T-SSP.
+
+   3.   O-Proxy examines the SED and discovers the domain is external.
+        Given the O-Proxy's internal routing policy, O-Proxy decides to
+        use O-SBE to reach T-SBE.  O-Proxy routes the INVITE request to
+        O-SBE and adds a Route header that contains O-SBE.
+
+
+
+Uzelac & Lee                  Informational                     [Page 6]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+         INVITE sip:+19175550100@example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP o-proxy.example.com:5060
+           ;branch=z9hG4bKye8ad
+         Via: SIP/2.0/TCP client.example.com:5060
+           ;branch=z9hG4bK74bf9;received=192.0.1.1
+         Max-Forwards: 9
+         Route: <sip:o-sbe1.example.com;lr>
+         Record-Route: <sip:o-proxy.example.com;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=12345
+         To: Bob <sip:+19175550100@example.com;user=phone>
+         Call-ID: abcde
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@client.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   4.   O-SBE receives the requests and pops the top entry of the Route
+        header that contains "o-sbe1.example.com".  O-SBE examines the
+        Request-URI and does an LRF for "example.net".  In this example,
+        the LRF is a Naming Authority Pointer (NAPTR) DNS query
+        [RFC3403] of the domain name.  O-SBE receives a NAPTR response
+        from the LRF.  The response looks similar to this:
+
+          IN NAPTR (
+            50
+            50
+            "S"
+            "SIP+D2T"
+            ""
+            _sip._tcp.t-sbe.example.net. )
+
+          IN NAPTR (
+            90
+            50
+            "S"
+            "SIP+D2U"
+            ""
+            _sip._udp.t-sbe.example.net. )
+
+   5.   Given the lower order for TCP in the NAPTR response, O-SBE
+        decides to use TCP as the transport protocol, so it sends an SRV
+        DNS query for the SRV record [RFC2782] for "_sip._tcp.t-
+        sbe.example.net." to O-LRF.
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 7]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+        ;;     priority  weight   port  target
+        IN SRV 0         2        5060  t-sbe1.example.net.
+        IN SRV 0         1        5060  t-sbe2.example.net.
+
+   6.   Given the higher weight for "t-sbe1.example.net", O-SBE sends an
+        A record DNS query for "t-sbe1.example.net." to get the A
+        record:
+
+          ;; DNS ANSWER
+          t-sbe1.example.net.   IN A   192.0.2.100
+          t-sbe1.example.net.   IN A   192.0.2.101
+
+   7.   O-SBE sends the INVITE to T-SBE.  O-SBE is the egress point to
+        the O-SSP domain, so it should ensure subsequent mid-dialog
+        requests traverse via itself.  If O-SBE chooses to act as a
+        back-to-back user agent (B2BUA) [RFC3261], it will generate a
+        new INVITE request in next step.  If O-SBE chooses to act as a
+        proxy, it should record-route to stay in the call path.  In this
+        example, O-SBE is a B2BUA.
+
+         INVITE sip:+19175550100@example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP o-sbe1.example.com:5060
+           ;branch= z9hG4bK2d4zzz
+         Max-Forwards: 8
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde-osbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   Note that O-SBE may re-write the Request-URI with the target domain
+   in the SIP URI.  Some proxy implementations will only accept the
+   request if the Request-URI contains their own domains.
+
+   8.   T-SBE determines the called party home proxy and directs the
+        call to the called party.  T-SBE may use ENUM lookup or other
+        internal mechanism to locate the home proxy.  If T-SSP uses ENUM
+        lookup, this internal ENUM entry is different from the external
+        ENUM entry populated for O-SSP.  In this example, the internal
+        ENUM query returns the UAS's home proxy.
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 8]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+         $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
+         IN NAPTR (
+           10
+           100
+           "u"
+           "E2U+SIP"
+           "!^.*$!sip:+19175550100@t-proxy.example.net!"
+           . )
+
+   9.   T-SBE receives the NAPTR record, and following the requirements
+        in [RFC3263], queries DNS for the SRV records indicated by the
+        NAPTR result.  Not finding any, the T-SBE then queries DNS for
+        the A record of domain "t-proxy.example.net.".
+
+          ;; DNS ANSWER
+          t-proxy.example.net.   IN A   192.0.2.2
+
+   10.  T-SBE is a B2BUA, so it generates a new INVITE and sends it to
+        UAS's home proxy:
+
+         INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP t-sbe1.example.net:5060
+           ;branch= z9hG4bK28uyyy
+         Max-Forwards: 7
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
+         Call-ID: abcde-tsbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                     [Page 9]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   11.  Finally, UAS's home proxy forwards the INVITE request to the
+        UAS.
+
+         INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP t-proxy.example.net:5060
+           ;branch= z9hG4bK28u111
+         Via: SIP/2.0/TCP t-sbe1.example.net:5060
+           ;branch= z9hG4bK28uyyy; received=192.2.0.100
+         Max-Forwards: 6
+         Record-Route: <sip:t-proxy.example.net:5060;lr>,
+           <sip:t-sbe1.example.net:5060;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
+         Call-ID: abcde-tsbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   12.  RTP is established between the UAC and UAS.  Note that the media
+        shown in Figure 2 passes through O-DBE and T-DBE, but the use of
+        DBE is optional.
+
+5.2.1.  Administrative Characteristics
+
+   The static direct peering use case is typically implemented in a
+   scenario where there is a strong degree of trust between the two
+   administrative domains.  Both administrative domains typically sign a
+   peering agreement that states clearly the policies and terms.
+
+5.2.2.  Options and Nuances
+
+   In Figure 2, O-SSP and T-SSP peer via SBEs.  Normally, the operator
+   will deploy the SBE at the edge of its administrative domain.  The
+   signaling traffic will pass between two networks through the SBEs.
+   The operator has many reasons to deploy an SBE.  For example, the
+   O-SSP may use [RFC1918] addresses for their UA and proxies.  These
+   addresses are not routable in the target network.  The SBE can
+   perform a NAT function.  Also, the SBE eases the operation cost for
+   deploying or removing Layer 5 network elements.  Consider the
+   deployment architecture where multiple proxies connect to a single
+   SBE.  An operator can add or remove a proxy without coordinating with
+   the peer operator.  The peer operator "sees" only the SBE.  As long
+   as the SBE is maintained in the path, the peer operator does not need
+   to be notified.
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 10]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   When an operator deploys SBEs, the operator is required to advertise
+   the SBE to the peer LRF so that the peer operator can locate the SBE
+   and route the traffic to the SBE accordingly.
+
+   SBE deployment is a decision within an administrative domain.  Either
+   one or both administrative domains can decide to deploy SBE(s).  To
+   the peer network, most important is to identify the next-hop address.
+   This decision does not affect the network's ability to identify the
+   next-hop address.
+
+5.3.  Static Direct Peering Use Case - Assisting LUF and LRF
+
+   This use case shares many properties with the Static Direct Peering
+   Use Case Section 5.2.  There must exist a pre-association between the
+   O-SSP and T-SSP.  The difference is O-SSP will use the Assisting LUF/
+   LRF Provider for LUF and LRF.  The LUF/LRF Provider stores the SED to
+   reach T-SSP and provides it to O-SSP when O-SSP requests it.
+
+                            +-----------------+
+                            |LUF/LRF Provider |
+                            |                 |
+                            |     +-------+   |
+                            |   +-+ A-LUF |   |
+                            |  /  | A-LRF |   |
+       +--------------------+ /  ++-------+   +---------------------+
+       |       O-SSP        |/  /             |         T-SSP       |
+       |       +------------/(4,5,6)          |        +-----+      |
+       |      /             | /               |        |T-LUF|      |
+       |    (2)           +-+/                |      +-|T-LRF|      |
+       |    /            /  |                 |     /  +-----+      |
+       |   /            /   |                 |    /(8,9)           |
+       |+-------+     +-----+                 +-----+      +-------+|
+       ||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
+       |+-------+     +-----+                 +-----+      +-------+|
+       |    |               |                 |                |    |
+       |   (1)              |                 |              (11)   |
+       |    |               |                 |                |    |
+       | +-----+      +-----+                 +-----+       +-----+ |
+       | | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | |
+       | +-----+      +-----+                 +-----+       +-----+ |
+       +--------------------+                 +---------------------+
+             example.com                            example.net
+
+
+             Static Direct Peering with Assisting LUF and LRF
+
+                                 Figure 3
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 11]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   The call flow looks almost identical to Static Direct Peering Use
+   Case except that Steps 2, 4, 5, and 6 involve the LUF/LRF Provider
+   instead of happening in O-SSP domain.
+
+   Similar to Static Direct Peering Use Case, the O-DBE and T-DBE in
+   Figure 3 are optional.
+
+5.3.1.  Administrative Characteristics
+
+   The LUF/LRF Provider supplies the LUF and LRF services for the O-SSP.
+   Taken together, the LUF/LRF Provider, O-SSP, and T-SSP form a trusted
+   administrative domain.  To reach the T-SSP, the O-SSP must still
+   require pre-arranged agreements for the peer relationship with the
+   T-SSP.  The Layer 5 policy is maintained in the O-SSP and T-SSP
+   domains, and the LUF/LRF Provider may not be aware of any Layer 5
+   policy between the O-SSP and T-SSP.
+
+   A LUF/LRF Provider can serve multiple administrative domains.  The
+   LUF/LRF Provider typically does not share SED from one administrative
+   domain to another administrative domain without appropriate
+   permission.
+
+5.3.2.  Options and Nuances
+
+   The LUF/LRF Provider can use multiple methods to provide SED to the
+   O-SSP.  The most commonly used are an ENUM lookup and a SIP Redirect.
+   The O-SSP should negotiate with the LUF/LRF Provider regarding which
+   query method it will use prior to sending a request to the LUF/LRF
+   Provider.
+
+   The LUF/LRF Providers must be populated with the T-SSP's AORs and
+   SED.  Currently, this procedure is non-standardized and labor
+   intensive.  A more detailed description of this problem has been
+   documented in the work in progress [DRINKS].
+
+5.4.  Static Indirect Peering Use Case - Assisting LUF and LRF
+
+   The difference between a Static Direct Use Case and a Static Indirect
+   Use Case lies within the Layer 5 relationship maintained by the O-SSP
+   and T-SSP.  In the Indirect use case, the O-SSP and T-SSP do not have
+   direct Layer 5 connectivity.  They require one or multiple Indirect
+   Domains to assist with routing the SIP messages and possibly the
+   associated media.
+
+   In this use case, the O-SSP and T-SSP want to form a peer
+   relationship.  For some reason, the O-SSP and T-SSP do not have
+   direct Layer 5 connectivity.  The reasons may vary, for example,
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 12]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   business demands and/or domain policy controls.  Due to this indirect
+   relationship, the signaling will traverse from the O-SSP through one
+   or multiple I-SSPs to reach the T-SSP.
+
+   In addition, the O-SSP is using a LUF/LRF Provider.  This LUF/LRF
+   Provider stores the T-SSP's SED pre-populated by the T-SSP.  One
+   important motivation to use the LUF/LRF Provider is that the T-SSP
+   only needs to populate its SED once to the provider.  Using an LUF/
+   LRF Provider allows the T-SSP to populate its SED once, while any
+   O-SSP T-SSP's SED can use this LUF/LRF Provider.  Current practice
+   has shown that it is rather difficult for the T-SSP to populate its
+   SED to every O-SSP who must reach the T-SSP's subscribers.  This is
+   especially true in the Enterprise environment.
+
+   Note that the LUF/LRF Provider and the I-SSP can be the same provider
+   or different providers.
+
+                            +------------------+
+                            | LUF/LRF Provider |
+                            |       I-SSP      |
+                            |      +-------+   |
+                            |   ---+ A-LUF |   |
+                            |  /   | A-LRF |   |
+       +--------------------+ /    +-------+   +---------------------+
+       |       O-SSP        |/     /           |         T-SSP       |
+       |      +-------------/     /            |        +-----+      |
+       |     /              |(4,5,6)           |        |T-LUF|      |
+       |    /               |   /              |   +----+T-LRF|      |
+       |  (2)             + +---               |  /     +-----+      |
+       |  /              /  |                  | /(9,10)             |
+       |+-------+     +-----+     +-----+      +-----+      +-------+|
+       ||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
+       |+-------+     +-----+     +-----+      +-----+      +-------+|
+       |    |               |                  |                |    |
+       |   (1)              |                  |               (12)  |
+       |    |               |                  |                |    |
+       | +-----+      +-----+     +-----+      +-----+       +-----+ |
+       | | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
+       | +-----+      +-----+     +-----+      +-----+       +-----+ |
+       +-------------------------------------------------------------+
+            example.com          example.org         example.net
+
+
+    Indirect Peering via an LUF/LRF Provider and I-SSP (SIP and Media)
+
+                                 Figure 4
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 13]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   The following is a high-level depiction of the use case:
+
+   1.   The UAC initiates a call via SIP INVITE to the O-Proxy.  The
+        O-Proxy is the home proxy for the UAC.
+
+         INVITE sip:+19175550100@example.com;user=phone SIP/2.0
+         Via: SIP/2.0/TCP client.example.com:5060
+           ;branch=z9hG4bK74bf9
+         Max-Forwards: 10
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=12345
+         To: Bob <sip:+19175550100@example.com;user=phone>
+         Call-ID: abcde
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@client.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   2.   The UAC knows the UAS's TN, but does not know the UAS's domain.
+        It appends its own domain to generate the SIP URI in the
+        Request-URI and TO header.  The O-Proxy checks the Request-URI
+        and discovers that the Request-URI contains the user parameter
+        "user=phone".  This parameter indicates that the Request-URI is
+        a phone number.  So, the O-Proxy will extract the TN from the
+        Request-URI and query the LUF for SED information from a routing
+        database.  In this example, the LUF is an ENUM database.  The
+        ENUM entry looks similar to this:
+
+          $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
+          IN NAPTR (
+            10
+            100
+            "u"
+            "E2U+SIP"
+            "!^.*$!sip:+19175550100@example.org!"
+            . )
+
+   Note that the response shows the next-hop is the SBE in I-SSP.
+   Alternatively, the O-SSP may have a pre-association with the I-SSP.
+   As such, the O-SSP will forward all requests that contain an external
+   domain in the Request-URI or an unknown TN to the I-SSP.  The O-SSP
+   will rely on the I-SSP to determine the T-SSP and route the request
+   correctly.  In this configuration, the O-SSP can skip Steps 2, 4, 5,
+   and 6 and forward the request directly to the I-SBE.  This
+   configuration is commonly used in the Enterprise environment.
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 14]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   3.   Given the O-Proxy's internal routing policy, the O-Proxy decides
+        to use the O-SBE to reach the I-SBE.  The O-Proxy routes the
+        INVITE request to the O-SBE and adds a Route header that
+        contains the O-SBE.
+
+         INVITE sip:+19175550100@example.org;user=phone SIP/2.0
+         Via: SIP/2.0/TCP o-proxy.example.com:5060
+           ;branch=z9hG4bKye8ad
+         Via: SIP/2.0/TCP client.example.com:5060
+           ;branch=z9hG4bK74bf9;received=192.0.1.1
+         Max-Forwards: 9
+         Route: <sip:o-sbe1.example.com;lr>
+         Record-Route: <sip:o-proxy.example.com;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=12345
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@client.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   4.   The O-SBE receives the requests and pops the top entry of the
+        Route header that contains "sip:o-sbe1.example.com".  The O-SBE
+        examines the Request-URI and does an LRF for "example.org".  In
+        this example, the LRF is a NAPTR DNS query of the domain.  The
+        O-SBE receives a response similar to this:
+
+          IN NAPTR (
+            50
+            50
+            "S"
+            "SIP+D2T"
+            ""
+            _sip._tcp.i-sbe.example.org. )
+
+          IN NAPTR (
+            90
+            50
+            "S"
+            "SIP+D2U"
+            ""
+            _sip._udp.i-sbe.example.org. )
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 15]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   5.   Given the lower order for TCP in the NAPTR response, the O-SBE
+        decides to use TCP for transport protocol, so it sends an SRV
+        DNS query for the SRV record for "_sip._tcp.i-sbe.example.org."
+        to the O-LRF.
+
+        ;;     priority  weight   port  target
+        IN SRV 0         2        5060  i-sbe1.example.org.
+        IN SRV 0         1        5060  i-sbe2.example.org.
+
+   6.   Given the higher weight for "i-sbe1.example.org", the O-SBE
+        sends a DNS query for an A record of "i-sbe1.example.org." to
+        get the A record:
+
+          ;; DNS ANSWER
+          i-sbe1.example.org.   IN A   192.0.2.200
+          i-sbe1.example.org.   IN A   192.0.2.201
+
+   7.   The O-SBE sends the INVITE to the I-SBE.  The O-SBE is the entry
+        point to the O-SSP domain, so it should ensure subsequent mid-
+        dialog requests traverse via itself.  If the O-SBE chooses to
+        act as a B2BUA, it will generate a new back-to-back INVITE
+        request in the next step.  If the O-SBE chooses to act as proxy,
+        it should record-route to stay in the call path.  In this
+        example, the O-SBE is a B2BUA.
+
+         INVITE sip:+19175550100@example.org;user=phone SIP/2.0
+         Via: SIP/2.0/TCP o-sbe1.example.com:5060
+           ;branch= z9hG4bK2d4zzz
+         Max-Forwards: 8
+         Route:  <sip:i-sbe1.example.org;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde-osbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   8.   The I-SBE receives the request and queries its internal routing
+        database on the TN.  It determines that the target belongs to
+        the T-SSP.  Since the I-SBE is a B2BUA, the I-SBE generates a
+        new INVITE request to the T-SSP.
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 16]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+         INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP i-sbe1.example.org:5060
+           ;branch= z9hG4bK2d4777
+         Max-Forwards: 7
+         Route: <sip:t-sbe1.example.net;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde-isbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   Note that if the I-SSP wants the media to traverse through the I-DBE,
+   the I-SBE must modify the Session Description Protocol (SDP) in the
+   Offer to point to its DBE.
+
+   9.   The T-SBE determines the called party home proxy and directs the
+        call to the called party.  The T-SBE may use ENUM lookup or
+        another internal mechanism to locate the home proxy.  If the
+        T-SSP uses ENUM lookup, this internal ENUM entry is different
+        from the external ENUM entry populated for O-SSP.  This internal
+        ENUM entry will contain the information to identify the next hop
+        to reach the called party.  In this example, the internal ENUM
+        query returns the UAS's home proxy.
+
+         $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
+         IN NAPTR (
+           10
+           100
+           "u"
+           "E2U+SIP"
+           "!^.*$!sip:+19175550100@t-proxy.example.net!"
+           . )
+
+   Note that this step is optional.  If the T-SBE has other ways to
+   locate the UAS home proxy, the T-SBE can skip this step and send the
+   request to the UAS's home proxy.  We show this step to illustrate one
+   of the many possible ways to locate UAS's home proxy.
+
+   10.  The T-SBE receives the NAPTR record and, following the
+        requirements in [RFC3263], queries the DNS for the SRV records
+        indicated by the NAPTR result.  Not finding any, the T-SBE then
+        queries DNS for the A record of domain "t-proxy.example.net.".
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 17]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+          ;; DNS ANSWER
+          t-proxy.example.net.   IN A   192.0.2.2
+
+   11.  T-SBE sends the INVITE to UAS's home proxy:
+
+         INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP t-sbe1.example.net:5060
+           ;branch= z9hG4bK28uyyy
+         Max-Forwards: 6
+         Record-Route: <sip:t-sbe1.example.net:5060;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde-tsbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   12.  Finally, the UAS's home proxy forwards the INVITE request to the
+        UAS.
+
+         INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
+         Via: SIP/2.0/TCP t-proxy.example.net:5060
+           ;branch= z9hG4bK28u111
+         Via: SIP/2.0/TCP t-sbe1.example.net:5060
+           ;branch= z9hG4bK28uyyy; received=192.2.0.100
+         Max-Forwards: 5
+         Record-Route: <sip:t-proxy.example.net:5060;lr>,
+           <sip:t-sbe1.example.net:5060;lr>
+         From: Alice <sip:+14085550101@example.com;user=phone>
+           ;tag=54321
+         To: Bob <sip:+19175550100@example.net;user=phone>
+         Call-ID: abcde-tsbe1
+         CSeq: 1 INVITE
+         <allOneLine>
+         Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
+         transport=tcp>
+         </allOneLine>
+
+   13.  In Figure 4, RTP is established between the UAC and UAS via the
+        O-DBE, I-DBE and T-DBE.  The use of DBE is optional.
+
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 18]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+5.4.1.  Administrative Characteristics
+
+   This use case looks very similar to the Static Direct Peering Use
+   Case with Assisting LUF and LRF.  The major difference is the O-SSP
+   and T-SSP do not have direct Layer 5 connectivity.  Instead, O-SSP
+   connects to the T-SSP indirectly via the I-SSP.
+
+   Typically, an LUF/LRF Provider serves multiple O-SSPs.  Two O-SSPs
+   may use different I-SSPs to reach the same T-SSP.  For example,
+   O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to
+   reach T-SSP.  Given the O-SSP and T-SSP pair as input, the LUF/LRF
+   Provider will return the SED of I-SSP that is trusted by O-SSP to
+   forward the request to T-SSP.
+
+   In this use case, there are two levels of trust relationship.  The
+   first trust relationship is between the O-SSP and the LUF/LRF
+   Provider.  The O-SSP trusts the LUF/LRF to provide the T-SSP's SED.
+   The second trust relationship is between the O-SSP and I-SSP.  The
+   O-SSP trusts the I-SSP to provide Layer 5 connectivity to assist the
+   O-SSP in reaching the T-SSP.  The O-SSP and I-SSP have a pre-arranged
+   agreement for policy.  Note that Figure 4 shows a single provider to
+   supply both LUF/LRF and I-SSP, but O-SSP can choose two different
+   providers.
+
+5.4.2.  Options and Nuances
+
+   Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP
+   may deploy SBE and DBE for NAT traversal, security, transcoding, etc.
+   The I-SSP can also deploy the SBE and DBE for similar reasons (as
+   depicted in Figure 4).
+
+5.5.  Static Indirect Peering Use Case
+
+   This use case shares many properties with the Static Indirect Use
+   Case with Assisting LUF and LRF.  The difference is that the O-SSP
+   uses its internal LUF/LRF to control the routing database.  By
+   controlling the database, the O-SSP can apply different routing rules
+   and policies to different T-SSPs.  For example, the O-SSP can use
+   I-SSP1 and Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to
+   reach T-SSP2.  Note that there could be multiple I-SSPs and multiple
+   SIP routes to reach the same T-SSP; the selection process is out of
+   scope of this document.
+
+
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 19]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+      +--------------------+-------------------+---------------------+
+      |       O-SSP        |       I-SSP       |         T-SSP       |
+      |      +-----+       |                   |        +-----+      |
+      |     -+O-LUF|       |                   |        |T-LUF|      |
+      |    / |O-LRF+\      |                   |   +----+T-LRF|      |
+      |   /  +-----+ \     |                   |  /     +-----+      |
+      |  /(2)         \(4,5,6)                 | /(9,10)             |
+      |+-------+     +-----+      +-----+      +-----+      +-------+|
+      ||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
+      |+-------+     +-----+      +-----+      +-----+      +-------+|
+      |    |               |                   |                |    |
+      |   (1)              |                   |               (12)  |
+      |    |               |                   |                |    |
+      | +-----+      +-----+      +-----+      +-----+       +-----+ |
+      | | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
+      | +-----+      +-----+      +-----+      +-----+       +-----+ |
+      +--------------------------------------------------------------+
+           example.com          example.org          example.net
+
+
+                Indirect Peering via I-SSP (SIP and Media)
+
+                                 Figure 5
+
+5.5.1.  Administrative Characteristics
+
+   The Static Indirect Peering Use Case is implemented in cases where no
+   direct interconnection exists between the originating and terminating
+   domains due to either business or physical constraints.
+
+   O-SSP <---> I-SSP = Relationship O-I
+
+   In the O-I relationship, typical policies, features, or functions
+   that deem this relationship necessary are number portability,
+   ubiquity of termination options, security certificate management, and
+   masquerading of originating VoIP network gear.
+
+   T-SSP <---> I-SSP = Relationship T-I
+
+   In the T-I relationship, typical policies, features, or functions
+   observed consist of codec "scrubbing", anonymizing, and transcoding.
+   The I-SSP must record-route and stay in the signaling path.  The
+   T-SSP will not accept any message sent directly from the O-SSP.
+
+
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 20]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+5.5.2.  Options and Nuances
+
+   In Figure 5, we show an I-DBE.  Using an I-DBE is optional.  For
+   example, the I-DBE can be used when the O-SSP and T-SSP do not have a
+   common codec.  To involve an I-DBE, the I-SSP should know the list of
+   codecs supported by the O-SSP and T-SSP.  When the I-SBE receives the
+   INVITE request, it will make a decision to invoke the I-DBE.  An
+   I-DBE may also be used if the O-SSP uses Secure Real-time Transport
+   Protocol (SRTP) [RFC3711] for media and T-SSP does not support SRTP.
+
+5.6.  On-Demand Peering Use Case
+
+   On-demand peering [RFC5486] describes how two SSPs form the peering
+   relationship without a pre-arranged agreement.
+
+   The basis of this use case is built on the fact that there is no pre-
+   established relationship between the O-SSP and T-SSP.  The O-SSP and
+   T-SSP do not share any information prior to the dialog initiation
+   request.  When the O-Proxy invokes the LUF and LRF on the Request-
+   URI, the terminating user information must be publicly available.
+   When the O-Proxy routes the request to the T-Proxy, the T-Proxy must
+   accept the request without any pre-arranged agreement with the O-SSP.
+
+   The On-demand Peering Use Case is uncommon in production.  In this
+   memo, we capture only the high-level descriptions.  Further analysis
+   is expected when this use case becomes more popular.
+
+5.6.1.  Administrative Characteristics
+
+   The On-demand Direct Peering Use Case is typically implemented in a
+   scenario where the T-SSP allows any O-SSP to reach its serving
+   subscribers.  The T-SSP administrative domain does not require any
+   pre-arranged agreement to accept the call.  The T-SSP makes its
+   subscribers information publicly available.  This model mimics the
+   Internet email model.  The sender does not need an pre-arranged
+   agreement to send email to the receiver.
+
+5.6.2.  Options and Nuances
+
+   Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP
+   can decide to deploy the SBE.  Since the T-SSP is open to the public,
+   the T-SSP is considered to be a higher security risk than static
+   model because there is no trusted relationship between the O-SSP and
+   T-SSP.  The T-SSP should protect itself from any attack launched by
+   an untrusted O-SSP.
+
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 21]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+6.  Acknowledgments
+
+   Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David
+   Schwartz, Eli Katz and Jeremy Barkan are the authors of the early
+   individual documents.  Their use cases are captured in this document.
+   Also, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, John
+   Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon Peterson,
+   Alexander Mayrhofer, and Jean-Francois Mule made many valuable
+   comments related to this document.  The editors would also like to
+   extend a special thank you to Spencer Dawkins for his detailed review
+   of this document.
+
+7.  Security Considerations
+
+   Session interconnect for VoIP, as described in this document, has a
+   wide variety of security issues that should be considered.  For
+   example, if the O-SSP and T-SSP peer through public Internet, the
+   O-SSP must protect the signaling channel and accept messages only
+   from an authorized T-SSP.  This document does not analyze the threats
+   in detail.  [RFC6404] discusses the different security threats and
+   countermeasures related to VoIP peering.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 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.
+
+   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
+              Protocol (SIP): Locating SIP Servers", RFC 3263,
+              June 2002.
+
+   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+              Part Three: The Domain Name System (DNS) Database",
+              RFC 3403, October 2002.
+
+
+
+
+
+Uzelac & Lee                  Informational                    [Page 22]
+
+RFC 6405               VoIP SIP Peering Use Cases          November 2011
+
+
+   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
+              Interconnect (SPEERMINT) Terminology", RFC 5486,
+              March 2009.
+
+   [RFC6116]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
+              Uniform Resource Identifiers (URI) Dynamic Delegation
+              Discovery System (DDDS) Application (ENUM)", RFC 6116,
+              March 2011.
+
+   [RFC6404]  Seedorf, J., Niccolini, S., Chen, E., and H. Scholz,
+              "Session PEERing for Multimedia INTerconnect (SPEERMINT)
+              Security Threats and Suggested Countermeasures", RFC 6404,
+              November 2011.
+
+8.2.  Informative References
+
+   [DRINKS]   Channabasappa, S., "Data for Reachability of Inter/
+              tra-NetworK SIP (DRINKS) Use cases and Protocol
+              Requirements", Work in Progress, August 2011.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              December 1998.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+Authors' Addresses
+
+   Adam Uzelac (editor)
+   Global Crossing
+   U.S.A.
+
+   EMail: adam.uzelac@globalcrossing.com
+   URI:   http://www.globalcrossing.com
+
+
+   Yiu L.Lee (editor)
+   Comcast Cable
+   U.S.A.
+
+   EMail: yiu_lee@cable.comcast.com
+   URI:   http://www.comcast.com
+
+
+
+Uzelac & Lee                  Informational                    [Page 23]
+