[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6405

     Internet Draft                                            A.Uzelac, Ed.
     SPEERMINT                                               Global Crossing
     Intended status: Informational                               Y.Lee, Ed.
     Expires: Aug 2008                                               Comcast
                                                            February 4, 2008
                             VoIP SIP Peering Use Cases
     Status of this Memo
        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she becomes
        aware will be disclosed, in accordance with Section 6 of BCP 79.
        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as Internet-Drafts.
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed at
        This Internet-Draft will expire on Aug 4, 2008.
        This document will capture VoIP use case for SIP Peering.  This
        document depicts many common VoIP peering use cases. These use cases
        are categorized into two types: static and on-demand, and then
        further subcategorized into direct and indirect. These use cases are
        not an exhaustive set, but rather the most common use cases deployed
        today. This document captures them to provide a reference.
     Uzelac, Lee (et al)      Expires Aug 4, 2008                   [Page 1]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     Table of Contents
        1. Introduction...................................................2
        2. Terminology....................................................3
        3. Reference Architecture.........................................3
        4. Contexts of Use Cases..........................................4
        5. Use Cases......................................................5
           5.1. Static Peering Use Cases..................................5
           5.1.1. Static Direct Peering Use Case..........................6
  Administrative characteristics........................7
  Options and Nuances...................................7
           5.1.2. Static Direct via Assisting Entity (Hub/Spoke)..........7
  Administrative Characteristics........................8
  Options and Nuances...................................8
           5.1.3. Static Indirect Use Cases...............................9
           5.1.4. Static Indirect Peering ? SIP and Media via I-SSP.......9
  Administrative characteristics.......................10
  Options and Nuances..................................10
           5.1.5. Static Indirect ? Signaling via I-SSP..................11
           5.2. On-demand Peering Use Cases..............................12
           5.2.1. On-demand Direct Peering Use Case......................12
  Administrative characteristics.......................12
  Options and Nuances..................................12
           5.3. Federations..............................................13
           5.3.1. Federation Considerations..............................13
           5.3.2. Federation Examples....................................13
  Trivial Federations..................................13
  Access List based....................................14
  TLS based Federations................................14
  Central SIP Proxy....................................14
        6. Architecture, scalability and business scalability............15
        7. Security Considerations.......................................15
        8. IANA Considerations...........................................15
           Normative References..........................................16
           Informative References........................................17
           Author's Addresses............................................17
           Full Copyright Statement......................................18
           Intellectual Property.........................................18
     1. Introduction
        This document attempts to capture VoIP use cases for Session
        Initiation Protocol (SIP)[1] based peering.  These use cases will
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 2]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
        assist in identifying requirements and future works for VoIP Peering
        using SIP.
        Only use cases related to VoIP are considered in this document.
        Other real-time SIP communications use cases, like Instant Messaging
        (IM) and presence are out of scope for this document.  In describing
        use cases, the intent is descriptive, not prescriptive.
        There are existing documents [2][3][4][5][6] that have captured use
        case scenarios.  This draft draws from those documents.  The document
        categories use cases into the following groupings; static or on-
        demand, then they are further subdivided into direct and indirect.
        Using this categorization, the use cases contained in this document
        attempts to be as comprehensive as possible, but should not be
        considered the exclusive set of use cases.
     2. Terminology
        In this document, we use ?O? to indicate ?Originating?, ?T? to
        indicate ?Terminating?, and  ?I? to indicate ?Indirect?. For example,
        O-SSP is the acronym of Originating SIP Service Provider.
     3. Reference Architecture
        The diagram below provides the reader with a context for the VoIP use
        cases in this draft.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 3]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
        |                   |   Indirect SSP Domain   |                   |
        |                   |                         |                   |
        |                   |    +------+ +------+    |                   |
        |                   |    +I-LUF + + I-LRF|    |                   |
        |                   |    +------+ +------+    |                   |
        |                   |                         |                   |
        |                   |        +-------+        |                   |
        |                   |        |I-Proxy|        |                   |
        |                   |        +-------+        |                   |
        |                   |                         |                   |
        |                   |    +------+ +------+    |                   |
        |                   |    | I-SBE| | I-DBE|    |                   |
        |                   \    +------+ +------+    /                   |
        |           +------+ \                       / +------+           |
        |     +-----+O-LUF +  \                     /  +T-LUF +-----+     |
        |     |     +O-LRF +   \                   /   +T-LRF +     |     |
        |     |     +------+    \                 /    +------+     |     |
        |     |                  \               /                  |     |
        |     |     +------+      \             /      +------+     |     |
        |     |     | O-SBE+       \           /       + T-SBE|     |     |
        |     |     +---+--+        \         /        +---+--+     |     |
        |     |         |            \       /             |        |     |
        |     |         |             \     /              |        |     |
        |     |     +---+---+          \   /           +---+---+    |     |
        |     +-----+O-Proxy|           \ /            |T-Proxy+--- +     |
        |           +-----+-+            +             ++------+          |
        |  +----+         |              |              |         +----+  |
        |  |UAC +---------+              |              +---------+ UAS|  |
        |  +----+         +------+       |       +------+         +----+  |
        |                 | O-DBE|       |       | T-DBE|                 |
        |                 +------+       |       +------+                 |
        |                                |                                |
        |     Originating SSP Domain     |        Terminating SSP Domain  |
        Figure 1 Generalized Overview
        PLEASE NOTE: In figure one ? the elements defined are optional in
        many use cases.
     4. Contexts of Use Cases
        Use cases are sorted into two general groupings: Static and On-demand
        Peering [15]. Each grouping can further sub-divided to Direct Peering
        and Indirect Peering [15]. Though there may be some overlap among the
        use cases in these categories, there are different requirements
        between the scenarios.  Each use-case has to specify how a few core
        operations which are to be performed by its members.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 4]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
        These can include:
        1) Peer Discovery via a Look-up function to determine the
        administrative domain to direct the call to.
        2) A location determination process that serves to create the Session
        Establishment Data (SED). Examples: Public User-ENUM, public
        Infrastructure ENUM, private ENUM tree, SIP Redirect, DUNDi.
        3) Next Hop determination based on the SED. If a location function
        query did not return an URI of the form sip:user@IP-address, then the
        originating SSP has to translate the domain part of the URI to an IP-
        address (plus perhaps fall-backs) in order to contact the next hop.
        Examples: RFC3263 in the public DNS. RFC3263 in a federation private
        DNS. RFC3263 in the public DNS with split-DNS, P2P SIP, modified
        RFC3263 in the public DNS (e.g. a federation-specific prefix to the
        domain name).
        4) Call setup ? SSPs that are interconnecting to one another may also
        define specifics on what SIP features need to be used when contacting
        the next hop in order to a) reach the next hop at all and b) to 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 L3 network),
        which TLS client certificate to use, other authentication scheme.
        5) Call reception ? This step serves to ensure that the type of
        relationship (static or on-demand, indirect or direct) is understood.
        For instance, the receiving side border elements need to determine
        whether the INVITE it just received really came from a member of the
        federation. This is the flip side of step four. Example: verify TLS
        cert, check incoming interface/VLAN,check source IP address against a
        configured list of valid ones.
     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 Speermint.
     5.1. Static Peering Use Cases
        Static Peering [15] describes two SSP form the peering relationship
        with pre-association.  Pre-association is a prerequisite to static
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 5]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     5.1.1. Static Direct Peering Use Case
        This is the simplest form of a peering use case. Two SSP negotiate
        and agree to establish a SIP peering relation. The peer connection is
        statically configured and directly connected two SSP. The peers may
        exchange peer information such as DSCP policies, subscriber SIP-URI
        and proxy location prior to establishing the connection. They only
        accept traffic originating directly from the trusted peer.
         |     Orig SSP     |     Term SSP      |
         |     +--------+   |     +--------+    |
         |     |  O-LUF |   |     |  T-LUF |    |
         |     |  O-LRF |   |     |  T-LRF |    |
         |     +--------+   |     +--------+    |
         |  (2) /           |                   |
         |   /(3)           |                   |
         |  +-------+       |       +-------+   |
         |  |O-Proxy|------(4)------|T-Proxy|   |
         |  +-------+       |       +-------+   |
         |      |           |           |       |
         |     (1)          |          (5)      |
         |      |           |           |       |
         |   +----+         |         +----+    |
         |   | UAC+===(6)=(RTP)=======+ UAS+    |
         |   +----+         |         +----+    |
        Figure 2 Direct Peering
        The following is a high-level depiction of the use case.
          1. UAC initiates a call via SIP INVITE
          2. O-Proxy queries for SED information from a routing database.
          3. Routing database entity replies with SED to called party
          4. Call sent to terminating domain proxy.
          5. T-Proxy determines called party status and directs call to
             called party.
          6. RTP is established between UAC and UAS.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 6]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
  Administrative characteristics
        The static direct peering use case is typically implemented in a
        scenario where exists a strong degree of trust between the two
        administrative domains. Both administrative domains normally sign a
        peer agreement which state clearly the peering policies and terms.
  Options and Nuances
        In Figure 2, O-Proxy and T-Proxy connect directly. An operator may
        decide to deploy a SBE between its proxy and the peer network.
        Normally, the operator will deploy the SBE in the edge of its
        administrative domain. The signaling traffic will pass between two
        networks through the SBE. The operator has many reasons to deploy a
        SBE. For example, the proxy may use RFC1918 addresses that are not
        routable in the peer operator network. The SBE can perform a NAT
        function. Also, the SBE eases the operation cost for deploying or
        removing L5 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 maintain
        intact, the peer operator does not need to be notified.
        When an operator deploys a SBE, 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
        administrative domain or both administrative domains can decide to
        deploy SBE. To the peer network, most important is to identify the
        next-hop address. Whether next-hop is a proxy or SBE, the peer
        network will not see any difference.
     5.1.2. Static Direct via Assisting Entity (Hub/Spoke)
        The difference between Direct and Indirect Use Cases is the O-SSP
        invokes an I-SSP to forward requests to T-SSP blindly, regardless of
        LUF or LRF. This use case is also referring to a ?transit? model of
        SIP peering. Similar to the On-demand Direct Use Case model, the I-
        SSP must publicly announce that it accepts request and is capable to
        route the request to the T-SSP.
        Another On-demand Indirect Use Case is the Hub-and-Spoke use case. An
        Assisting entity where only the LRF resides, serves as the hub for
        multiple SSPs. Each SSP is the spoke to the Assisting Entity which
        does not need to have direct L5 connections among other SSPs. To
        originate a call to a T-SSP, the O-SSP will query the Assisting
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 7]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
        Entity?s LRF. The response will facilitate indirect or direct
        communications to the O-SSP. The Assisting entity can route the
        Session to one of its served SSP.  The routing logic in the Assisted
        Entity is hidden to the SSP. Figure 4 shows the high-level network
                               | Entity  |
                               |  (LRF)  |
                                  | | |
                                  | | |
                                  | | |
                 +----------------+ | +------------------+
                 |                  |                    |
                 |                  |                    |
                 |                  |                    |
             +---+----+         +---+----+           +---+----+
             |        |         |        |           |        |
             |  SSP1  |         |  SSP2  |  .......  |  SSPx  |
             |        |         |        |           |        |
             +--------+         +--------+           +--------+
        Figure 3 Hub and spoke
  Administrative Characteristics
        The Hub-and-Spoke Use Case is commonly used in a Registry or
        Directory call model, where both O-SSP and T-SSP do not have direct
        Layer-5 connectivity. O-SSP and T-SSP choose an I-SSP and forms a
        trusted relationship to I-SSP. As such, the I-SSP is the hub served
        multiple spoke SSPs. Spoke SSP only have trusted relationship with I-
        SSP. Spoke SSPs do not have trusted relationship among themselves.
        They use I-SSP to assist them to route the signaling traffic. That
        said, if Spoke SSPs have direct Layer-3 connectivity, Spoke SSP can
        choose not to use I-SSP assistance for media traffic.
  Options and Nuances
        T-SSP shares the same problems of which On-demand Indirect Use Case
        suffers. T-SSP should apply filter rules for VoIP spam. O-SSP, T-SSP
        and I-SSP can deploy SBE and DBE for NAT traversal, admission control
        and codec Transcoding.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 8]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     5.1.3. Static Indirect Use Cases
        Similar to the Static Direct Peering Use Case, O-SSP and T-SSP has
        pre-arranged assignment for the peer relationship. The difference
        between Static Direct Use Case and Static Indirect Use Case lies with
        the Layer-5 relationship O-SSP and T-SSP maintain.  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
        routing the SIP messages and possibly the associated media.
     5.1.4. Static Indirect Peering ? SIP and Media via I-SSP
        In the following use case, all signaling and media between the O-SSP
        and T-SSP flows through another SSP (Indirect SSP).
                             |    Indirect SSP    |
                             |                    |
                             |       +-------+    |
                             |    +--+I-Proxy|    |
                             |   / +-+ I-LUF |    |
                             |  / /  + I-LRF |    |
        +--------------------+ / /   +-------+    +---------------------+
        |    Orig SSP        |/ /                 |      Term SSP       |
        |      +-------------/ /                  |                     |
        |     /              |/                   |                     |
        |    /  +----(3)-----+                    |                     |
        |  (2) /             |                    |                     |
        |  /  /              |                    |                     |
        |+-------+     +-----+      +-----+       +-----+     +-------+ |
        ||O-Proxy|-(4)-|O-SBE|------+I-SBE+--(5)--+T-SBE+-(6)-|T-Proxy| |
        |+-------+     +-----+      +-----+       +-----+     +-------+ |
        |    |               |                    |               |     |
        |   (1)              |                    |              (7)    |
        |    |               |                    |               |     |
        | +-----+      +-----+      +-----+       +-----+      +-----+  |
        | | UAC +======|0-DBE|=(8)==+I-DBE+=======+T-DBE+======+ UAS |  |
        | +-----+      +-----+      +-----+       +-----+      +-----+  |
        Figure 4 Indirect Peering via Indirect Domain (SIP and media)
          1. UAC initiates a call.
          2. The O-Proxy queries SED for the called party. O-SSP can query
             its own LUF and LF for the SED if the information is available
             within its domain. Alternatively, the I-SSP may provide the LUF
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                   [Page 9]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
             and LF for the O-SSP. In this setup, the query traverses the
             administrative boundary between the originating and the Indirect
             domains (as illustrated in Fig. 3).
          3. The result of the query will be the I-SSP?s SBE (I-SBE) that is
             interconnected to the T-SSP and the O-SBE.
          4. O-Proxy signals the I-SBE via the O-SBE.
          5. I-SBE routes call to T-SBE within T-SSP.
          6. T-SBE signals T-Proxy.
          7. T-Proxy signals the called party. (UAS)
          8. RTP may be established between UAC and UAS via DBE path
             typically coordinated by the I-SSP.
  Administrative characteristics
        The Static Indirect Use Case is normally implemented in cases where
        no direct interconnection exists between 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 NP, Ubiquity of termination
        options, 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?, anonimizing, and transcoding.
        I-SSP must record-route and stay in the signalling path. T-SSP will
        not accept message directly sent from O-SSP.
  Options and Nuances
        Similar to the Static Direct Peering Use Case, O-SSP and T-SSP may
        deploy SBE and DBE for NAT traverse, security Transcoding, etc. I-SSP
        can also deploy SBE and DBE for similar reasons. (as depicted in Fig.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 10]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     5.1.5. Static Indirect ? Signaling via I-SSP
        The static indirect use case with signaling only shares many
        properties with the static indirect use case for signaling and media.
        There must exist a pre-associate between the O-SSP and T-SSP, but the
        situation only pertains to administrative relations.  The O and T
        SSPs do not have direct Layer-5 connectivity; therefore require one
        or multiple Indirect Domains to assist routing the SIP messages.
                              |    Indirect SSP    |
                              |                    |
                              |       +-------+    |
                              |    +--+I-Proxy|    |
                              |   / +-+ I-LUF |    |
                              |  / /  + I-LRF |    |
         +--------------------+ / /   +-------+    +---------------------+
         |    Orig SSP        |/ /                 |      Term SSP       |
         |      +-------------/ /                  |                     |
         |     /              |/                   |                     |
         |    /  +----(3)-----+                    |                     |
         |  (2) /             +--------------------+                     |
         |  /  /              |                    |                     |
         |+-------+     +-----+                    +-----+     +-------+ |
         ||O-Proxy|-----|O-SBE+--------(4)---------+T-SBE+-(5)-|T-Proxy| |
         |+-------+     +-----+                    +-----+     +-------+ |
         |    |               |                    |               |     |
         |   (1)              |                    |              (6)    |
         |    |               |                    |               |     |
         | +-----+      +-----+                    +-----+      +-----+  |
         | | UAC +======|0-DBE|========(7)=========+T-DBE+======+ UAS |  |
         | +-----+      +-----+                    +-----+      +-----+  |
         +--------------------+                    +---------------------+
        Figure 5 Indirect via I-SSP (SIP only)
          1. UAC initiates a call.
          2. The O-Proxy queries SED for the called party. O-SSP can query
             its own LUF and LF for the SED if the information is available
             within its domain. Alternatively, the I-SSP may provide the LUF
             and LF for the O-SSP. In this setup, the query traverses the
             administrative boundary between the originating and the Indirect
             domains (as illustrated in Fig. 4).
          3. The result of the query will be the T-SSP?s SBE (T-SBE) that is
             interconnected to the O-SSP via the O-SBE.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 11]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
          4. O-SBE signals the T-SBE.
          5. T-SBE signals T-Proxy.
          6. T-Proxy signals the called party, UAS.
          7. RTP may be established between UAC and UAS via DBE path
             typically coordinated by the I-SSP.
     5.2. On-demand Peering Use Cases
        On-demand Peering [15] describes two SSPs form the peering
        relationship without a pre-arranged agreement.
     5.2.1. On-demand Direct Peering Use Case
        The basis of this use case is built on the fact that there is NOT a
        pre-established relationship between the O-SSP and the T-SSP. The O-
        SSP and T-SSP did not share any information prior to the dialog
        initiation request. When the O-Proxy invokes the LUF and LRF on the
        R-URI, the terminating user information must be publicly available.
        Besides, when the O-Proxy routes the request to the T-Proxy, the T-
        Proxy must accept the request without any pre-association with O-SSP.
        The call flow is identical to the Static Direct Peering Use Case
        shown in Fig 2.
  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. T-SSP administrative domain does not require any pre-
        arranged agreement to accept the call. T-SSP makes its subscribers
        information available in public. This model mimics the Internet email
        model. Sender does not need an pre-arranged agreement to send email
        to the receiver.
  Options and Nuances
        Similar to Static Direct Peering Use Case, O-SSP and T-SSP can decide
        to deploy SBE. T-SSP is open to the public, T-SSP should prepare to
        suffer from the spam problem existing in email system. VoIP spamming
        is considered more annoying than email spamming to the subscribers.
        T-SSP should apply rules to filter spammed calls.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 12]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     5.3. Federations
        This section discusses the federation concept, explains which
        technical parameters make up the foundation of a federation and
        provides examples.
        The concrete implementation details (e.g. "direct with one SBE"
        versus "direct with two SBEs") can involve all the use cases thus far
        described in the document.
     5.3.1. Federation Considerations
     5.3.2. Federation Examples
          This section lists some examples of how federations can operate.
  Trivial Federations
          A private peering arrangement between two SSPs is a special case of
          a federation. These two SSP have agreed to exchange calls amongst
          themselves and they have set up whatever LUF/LS/SBE plus Layer 3
          infrastructure they need to route and complete the calls.  This can
          be in a direct or indirect manner, but usually follows the direct
          call model.
          It is thus not needed to treat bi-lateral peerings as conceptually
          different to federation-based peering.
          On the other extreme, the set of all SSPs implementing an open SIP
          service according to RFCs 3261/3263/3761 also fulfills the
          definition of a federation.  In that case, the technical rules are
          contained in these three RFCs, the LS is the public DNS. Whether
          some of these SSPs use SBCs as border elements is not relevant.
          The administrative model of this federation is the "email model":
          There is no "member list", any SIP server operating on the Internet
          which implements call routing according to these RFCs is implicitly
          a member of that federation. No business relationship is needed
          between "members", thus no money is likely to change hands for
          terminating calls. There is no contractual protection against
          nuisance calls, SPIT, or denial of service attacks.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 13]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
  Access List based
          If running an open SIP proxy is not desired, then a group of SSPs
          which want to allow calls from each other can collect the list of
          IP addresses of all their border elements.
          This list is redistributed to all members which use it to configure
          firewalls in front of their ingress elements.  Thus calls from
          other members of this federation are accepted while calls from
          other hosts on the Internet are blocked.
          Whether SSPs deploy SBEs as border elements is not relevant.  Call
          routing can still be done via standard RFC rules.
          Whenever a new member joins this club every other SSP needs to
          adapt its filter rules.
  TLS based Federations
          Another option to restrict incoming calls to federation members is
          to use Transport Layer Security (TLS) certificates as access
          control. This works best if the federation runs a certificate
          authority (CA) which signs the TLS keys of each member SSP.  Thus
          the ingress element of a SSP needs to check only whether the client
          certificate presented by the calling SIP proxy contains a proper
          signature from that CA.
          Adding support for Certificate Revocation Lists solves the issue of
          blocking calls from former members of that federation.  The main
          benefit of this model is that no changes need to be made at the
          ingress element of all old members whenever a SSP joins that
  Central SIP Proxy
          One way to simplify the management of these firewall rules is to
          route all SIP messages via a central proxy.
          In that case, all federation members just need to open up their
          ingress elements to requests from that central server. A new SSP
          just triggers a change in the configuration of this box and not at
          all other SSPs.
          While centralized solutions may entail typical hub-and-spoke
          architecture considerations, the added overall federation
          scalability with respect to the number of interconnects required,
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 14]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
          their associated policies and management make this approach quite
          popular today.
          This is an example of Indirect Peering.
     6. Architecture, scalability and business scalability
          The network architecture which in the case centralized model would
          reflect a hub and spoke model - should be weighed against a
          distributed model. While such a centralized model presents well-
          known network and server scalability challenges, a distributed
          model requires higher interconnection complexity, reflected in
          provisioning and the need for the maintenance of such
     7. Security Considerations
          This document introduces no new security considerations.  However,
          it is important to note that session interconnect, as described in
          this document, has a wide variety of security issues that should be
          considered in documents addressing both protocol and use case
     8. IANA Considerations
          This document creates no new requirements on IANA namespaces
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 15]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     Normative References
        [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
              Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
              Session Initiation Protocol", RFC 3261, June 2002.
        [2]   Schwartz, David, draft-schwartz-speermint-use-cases-federations
        [3]   Mahy, Rohan, draft-mahy-speermint-direct-peering
        [4]   Lendl, Otmar, draft-lendl-speermint-federations
        [5]   Lee, Yiu, draft-lee-speermint-use-case-cable
        [6]   Uzelac, Adam, draft-uzelac-speermint-use-cases
        [7]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
              (SIP): Locating SIP Servers", RFC 3263, June 2002.
        [8]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
              T. Wright, "Transport Layer Security (TLS) Extensions", RFC
              3546, June 2003.
        [9]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
              "RTP: A Transport Protocol for Real-Time Applications", STD 64,
              RFC 3550, July 2003.
        [10]  Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
              numbers with the Session Initiation Protocol (SIP)", RFC 3824,
              June 2004.
        [11]  Peterson, J., ?Address Resolution for Instant Messaging and
              Presence?,RFC 3861, August 2004.
        [12]  Peterson, J., "Telephone Number Mapping (ENUM) Service
              Registration for Presence Services", RFC 3953, January 2005.
        [13]  ETSI TS 102 333: " Telecommunications and Internet converged
              Services and Protocols for Advanced Networking (TISPAN); Gate
              control protocol".
        [14]  Peterson, J., "enumservice registration for Session Initiation
              Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 16]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     Informative References
        [15]  Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-
              terminology-06 (work in progress), 2006.
        [16]  Mule, J-F., ?SPEERMINT Requirements for SIP-based VoIP
              Interconnection?, draft-ietf-speermint-requirements-00.txt,
              June 2006.
        [17]  Camarillo, G. ?Requirements from SIP (Session Initiation
              Protocol) Session Border Control Deployments?, draft-camarillo-
              sipping-sbc-funcs-04.txt, June, 2006.
        [18]  Habler, M., et al., ?A Federation based VOIP Peering
              Architecture?, draft-lendl-speermint-federations-03.txt,
              September 2006.
     Author's Addresses
        Adam Uzelac
        Global Crossing
        Email: adam.uzelac@globalcrossing.com
        Rohan Mahy
        Email: rohan@ekabal.com
        Yiu L. Lee
        Comcast Cable Communications
        Email: yiu_lee@cable.comcast.com
        David Schwartz
        Xconnect Global Networks
        Email: dschwartz@xconnect.net
        Eli Katz
        Xconnect Global Networks
        Email: ekatz@xconnect.net
        Otmar Lendl
        enum.at GmbH
        Email: otmar.lendl@enum.at
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 17]

     Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Aug 2008
     Full Copyright Statement
          Copyright (C) The IETF Trust (2008).
          This document is subject to the rights, licenses and restrictions
          contained in BCP 78, and except as set forth therein, the authors
          retain all their rights.
          This document and the information contained herein are provided on
     Intellectual Property
          The IETF takes no position regarding the validity or scope of any
          Intellectual Property Rights or other rights that might be claimed
          to pertain to the implementation or use of the technology described
          in this document or the extent to which any license under such
          rights might or might not be available; nor does it represent that
          it has made any independent effort to identify any such rights.
          Information on the procedures with respect to rights in RFC
          documents can be found in BCP 78 and BCP 79.
          Copies of IPR disclosures made to the IETF Secretariat and any
          assurances of licenses to be made available, or the result of an
          attempt made to obtain a general license or permission for the use
          of such proprietary rights by implementers or users of this
          specification can be obtained from the IETF on-line IPR repository
          at http://www.ietf.org/ipr.
          The IETF invites any interested party to bring to its attention any
          copyrights, patents or patent applications, or other proprietary
          rights that may cover technology that may be required to implement
          this standard.  Please address the information to the IETF at ietf-
          Funding for the RFC Editor function is provided by the IETF
          Administrative Support Activity (IASA).
     Uzelac, Lee (et al.)     Expires Aug 4, 2008                  [Page 18]

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