GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6405

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6405.txt · Last modified: 2011/11/05 01:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki