One document matched: draft-ietf-speermint-voip-consolidated-usecases-03.txt
Differences from draft-ietf-speermint-voip-consolidated-usecases-02.txt
Internet Draft A.Uzelac
SPEERMINT Global Crossing
Intended status: Informational Y.Lee
Expires: May 2008 Comcast
D.Schwartz
Kayote Networks
E. Katz
Xconnect
O.Lendl
enum.at
R.Mahy
Plantronics
November 9, 2007
VoIP SIP Peering Use Cases
draft-ietf-speermint-voip-consolidated-usecases-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007)
Uzelac (et al) Expires May 9, 2008 [Page 1]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
Abstract
This document will capture VoIP use case for SIP Peering. It is a
consolidation of Speermint use cases drafts. This document depicts
many common VoIP peering use cases. These use cases are categorized
into three types: Direct, Indirect and Assisted. They are not the
exhaust set of use cases but the most common use cases deployed in
production today. This document captures them to provide a reference.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Contexts of Use Cases..........................................5
3.1. Direct Peering............................................5
3.2. Indirect Peering..........................................6
3.3. Assisted Peering..........................................6
4. Functions in the Use Cases.....................................6
4.1. Look-Up Function..........................................6
4.2. Location Function.........................................6
4.3. Signaling Function........................................6
4.4. Media Function............................................7
5. Use Cases......................................................7
5.1. On-demand Peering Use Cases...............................7
5.1.1. Direct On-demand Use Case...............................7
5.1.1.1. Administrative characteristics........................8
5.1.1.2. Options and Nuances...................................8
5.1.2. Indirect On-demand Use Case.............................9
5.1.2.1. Administrative Characteristics.......................10
5.2. Assisted Use Cases.......................................11
5.2.1. Assisted PSP Use Case..................................11
5.2.2. Assisted SSP (Hub-and-Spoke)...........................12
6. Federations...................................................13
6.1. Federation Considerations................................13
6.2. Federation Examples......................................15
6.2.1. Trivial Federations....................................15
6.2.2. Access List based......................................15
6.2.3. TLS based Federations..................................16
6.2.4. Central SIP Proxy......................................16
6.2.4.1. Architecture, scalability and business scalability...16
6.2.5. Private Layer 3 Network................................17
6.2.6. Peer to Peer SIP.......................................17
6.2.7. DUNDi..................................................17
7. Security Considerations.......................................18
8. IANA Considerations...........................................18
Uzelac (et al.) Expires May 9, 2008 [Page 2]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
References.......................................................19
Normative References..........................................19
Informative References........................................20
Author's Addresses............................................20
Full Copyright Statement......................................21
Intellectual Property.........................................21
Acknowledgment................................................21
1. Introduction
This document attempts to capture VoIP use cases for Session
Initiation Protocol (SIP)[1] based peering. These use cases will
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
contains three categories of use cases; Direct, Indirect and
Assisted. The use cases contained in this document attempts to be as
comprehensive as possible, but should not be considered the exclusive
set of user cases.
2. Terminology
Many terms in this document are referenced to the Speermint
terminology draft [15]. We also use few additional terms to describe
the VoIP use cases. We define them in this section.
o Location Server (LS): A server called upon by originating SSP,
either Local or Remote, to obtain the Session Establish Data
(SED). Often, the input to the server is an E.164 number and the
SED is a SIP URI. The originating SSP's client may call the
Location Function using ENUM Query/Response, SIP Invite/Redirect,
or other method depending on orginating SSP's infrastructure and
methods available for the data being interrogated, with the
response format being appropriate to the Query format. In the
case of an ENUM Query, the response should be a NAPTR record
containing the sip URI that can be resolved by the client. In the
case of a SIP Invite/Redirect, the response should be a SIP
Redirect (30X) message containing the URI.
Uzelac (et al.) Expires May 9, 2008 [Page 3]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
o Session Manager (SM): A SM is the home registrar of the user
endpoint. SM is responsible to receive and send SIP messages from
the peer. If the user endpoint speaks non-SIP, SM will translate
the non-SIP protocol to SIP protocol and vice versa.
o Session Border Element (SBE) : A SBE performs signaling sanitation
and security tasks in the signaling plane of Session
establishment. Common threats may be DOS or intentionally
malformed packet/headers. This device may perform NAT/PAT or
enable far-end NAT traversal.
o Data Border Element (DBE) : The DBE performs similar functions as
the SBE, but in the media or data plane.
o User Endpoint (UE): User Endpoint is the client that makes or
receives calls. UE can be sip based or non-sip based. For non-sip
based UE, SM acts as a signaling gateway and translates the non-
sip signaling to sip signaling before sending to SBE.
In this document, we use “O” to indicate “Originating”, “T” to
indicate “Terminating”, and “t” to indicate “Transit”. For example,
O-SBE is the acronym of Originating SBE.
Uzelac (et al.) Expires May 9, 2008 [Page 4]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
+-------------+-------------------------------------+------------+
| \ Assisting SSP Domain / |
| \ / |
| \ +------+ +------+ / |
| \ + a-LS + + a-SM | / |
| \ +------+ +-----++ / |
| \ +------+ +------+ / |
| +------+ \ | a-SBE| | a-DBE| /+------+ |
| +-----+ O-LS + \ +------+ +------+ / + T-LS +-----+ |
| | +------+ \ / +------+ | |
| | \ / | |
| | \ / | |
| | +------+ \ / +------+ | |
| | | O-SBE+ \ / + T-SBE| | |
| | +---+--+ \ / +------+ | |
| | | \ / | |
| | | \ / | |
| | +---+--+ \ / +------+ | |
| +-----+ O-SM | \ / | T-SM +-----+ |
| +-----++ + ++-----+ |
| +----+ | | | +----+ |
| |O-UE+---------+ | +---------+T-UE| |
| +----+ +------+ | +------+ +----+ |
| | 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.
3. Contexts of Use Cases
Use cases are sorted into 3 general groupings: Direct, Indirect and
Assisted. Though there may be some overlap among the use cases in
these categories, there are different requirements between the
scenarios and this document serves to help identify the requirements
for SIP Peering for VoIP. The following definitions are taken from
the Speermint Terminology draft[15].
3.1. Direct Peering
Direct peering describes those cases in which two service providers
interconnect without using an intervening layer 5 network.
Uzelac (et al.) Expires May 9, 2008 [Page 5]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
3.2. Indirect Peering
Indirect, or transit, peering refers to the establishment of either a
signaling and media path or signaling path alone via one (or more)
referral or transit network(s). In this case it is generally required
that a trust relationship is established between the originating
service provider and the transit network on one side, and the transit
network and the termination network on the other side.
3.3. Assisted Peering
In this case, some entity (usually a 3rd party or federation)
provides peering assistance to either the originating or terminating
SIP Service Provider (SSP) by providing one or more functions
assisting in the routing of SIP requests and the establishment of SIP
dialogs and sessions between peers. The assisting entity may provide
information relating to direct or indirect peering as necessary.
4. Functions in the Use Cases
Each use case will follow functions as defined in the Speermint
Terminology draft [15].
4.1. Look-Up Function
The Look-Up Function (LUF) provides a mechanism for querying an
internal and/or external database, which maintains a list of SIP user
name and associated peering domains.
4.2. Location Function
The Location Function (LF) develops call routing data (CRD) by
discovering the Signaling Function (SF) and the SF’s reachable host
(IP Address and port).
4.3. Signaling Function
The Signaling Function (SF) performs routing of SIP messages, to
optionally perform termination and re-initiation of a sessions, and
to assist in the discovery/exchange of parameters to be used ny the
Media Function
Uzelac (et al.) Expires May 9, 2008 [Page 6]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
4.4. Media Function
The Media Function (MF) performs media related function suck as
media, DTMF, etc transcoding and media security implementation
between two (or more) SSPs.
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 is germane to Speermint.
5.1. On-demand Peering Use Cases
On-demand Peering [15] describes two SSP form the peering
relationship without pre-arranged agreement.
5.1.1. Direct On-demand 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-SM invokes the LUF and LF on the R-
URI, the terminating user information must be publicly available.
Besides, when the O-SM routes the request to the T-SM, the T-SM must
accept the request without any pre-association with O-SSP.
Given the O-SSP policy, the O-SM may invoke A-SSP for one or more
assistances. In On-demand peering, the A-SSP must publicly announce
what assisted functions it provides and accept any on-demand request.
The following is a high-level depiction of the On-demand use case.
1. O-UE initiates a call via SIP INVITE
2. O-SM queries for next-hop information from a routing database.
This is the Look-up Function as described in the terminology
draft.
3. Routing database entity replies with route to called party
4. Call sent to terminating domains session manager.
5. Session manager determines called party status and directs call
to called party.
6. RTP is established between O-UE and T-UE.
Uzelac (et al.) Expires May 9, 2008 [Page 7]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
+------------------+-------------------+
| Orig Domain | Term Domain |
| +--------+ | +--------+ |
| | O-LS | | | T-LS | |
| +--------+ | +--------+ |
| (2) / | |
| /(3) | |
| +-----+ | +-----+ |
| |O-SM |--------(4)---------|T-SM | |
| +-----+ | +-----+ |
| | | | |
| (1) | (5) |
| | | | |
| +----+ | +----+ |
| |O-UE+===(6)=(RTP)=========+T-UE+ |
| +----+ | +----+ |
+------------------+-------------------+
Figure 2 Direct Peering
5.1.1.1. Administrative characteristics
The direct use case is typically implemented in a scenario where
exists a strong degree of trust between the 2 administrative domains.
Both administrative domains normally sign a peer agreement which
state clearly the peering policies and terms.
5.1.1.2. Options and Nuances
In Figure 2, O-SM and T-SM connect directly. An operator may decide
to deploy a SBE between its SM 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 SM may use RFC1918 addresses that are not routable in the peer
operator network. The SBE can perform NAT function. Also, the SBE
eases the operation cost for deploying old or removing new SM.
Consider the deployment architecture where multiple SMs connect to a
single SBE. An operator can add or remove a SM 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 LS so that the peer operator can locate the SBE
and route the traffic to the SBE accordingly.
Uzelac (et al.) Expires May 9, 2008 [Page 8]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
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 SM or SBE, the peer network
will not see any difference.
5.1.2. Indirect On-demand Use Case
The difference between Direct and Indirect Use Case is the O-SSP
invokes an A-SSP to forward requests to blindly, regardless of LUF or
LF. This use case is also referring to a “transit” model of SIP
peering. Similar to the Direct Use Case model, the A-SSP must
publicly announce that it accepts request and is capable to route the
request to the T-SSP.
Given the O-SSP policy, the O-SM may invoke a A-SSP similar to the
procedures described in the Direct On-demand Use Case.
1. O-UE initiates a call.
2. The O-SM performs next-hop determination for the called party.
This look-up traverses the administrative boundary between the
originating and the assisting domain.
3. The result of the query will be the assisting domains’s SBE (t-
SBE) that is interconnected to the transit domain via the O-SBE.
4. O-SM signals the t-SBE via the O-SBE.
5. t-SBE routes call to T-SBE within terminating domain.
6. T-SBE signals T-SM.
7. T-SM signals the called party, T-UE.
8. RTP is established between UEs via DBE path typically
coordinated by the Transit Domain.
Uzelac (et al.) Expires May 9, 2008 [Page 9]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
+------------------+
| Transit Domain |
| |
| +------+ |
| +--+ t-SM | |
| / +-+ t-LS | |
| / / +------+ |
+------------------+ / / +----------------------+
| Orig Domain |/ / | Term Domain |
| +-----------+ / | +--------+ |
| / |/ | | T-LS | |
| / +----(3)---+ | +--------+ |
| (2) / | | |
| / / | | |
|+-----+ +-----+ +-----+ +-----+ +-----+|
||O-SM |-(4)-|O-SBE|------+t-SBE+-(5)-+T-SBE+---(6)---|T-SM ||
|+-----+ +-----+ +-----+ +-----+ +-----+|
| | | | | | |
| (1) | | | (7) |
| | | | | | |
| +----+ +-----+ +-----+ +-----+ +----+|
| |O-UE+=====|0-DBE|=(8)==+t-DBE+=====+T-DBE+==========+T-UE||
| +----+ +-----+ +-----+ +-----+ +----+|
+------------------------------------------------------------+
Figure 3 Indirect via Transit PSP
5.1.2.1. Administrative Characteristics
The transit peering use case is normally implemented in cases where
no direct interconnection exists between originating and terminating
domains due to either business or physical constraints.
Orig Domain .--. Transit = Relationship O-T
In the O-T relationship, typical policies, features or functions that
deem this relationship necessary are NP, Ubiquity of termination
options, and masquerading of originating VoIP network gear.
Term Domain .--. Transit = Relationship T-T
In the T-T relationship, typical policies, features or functions
observed consist of codec “scrubbing”, anonimizing, and transcoding.
Uzelac (et al.) Expires May 9, 2008 [Page 10]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
5.2. Assisted Use Cases
Assisted use cases involve an assisting SSP (A-SSP) that facilitates
direct session establishment between the O-SSP and T-SSP. There may
be elements that provide SIP proxy functionality, and are often
implemented in practice by SBE(s) and DBE(s) which may "filter" or
"normalize" and provide network-hiding for incoming messages en route
to their final destination. Fear and distrust coupled with continued
interoperability and security concerns have revived the need for the
neutral central element role enabled by this peering model.
Popularity of this model can be attributed to the concentration of
functions provided by A-SSP. As an external element, A-SSP can
provide the full set of services for SSPs, and through its own
relationships with the SSP eliminate the need of all SSPs for pair-
wise service relationships. A-SSP can potentially encompass a large
namespace of users that is accessible in one query to external SSP
members (or not -depending on policy).
In addition there is an interoperability function usually performed
by an A-SSP SBE, almost guaranteeing interoperability and protocol
interchangeability between member SSPs. As part of the
interoperability there is also is media sub-function enabling the
federation to enforce a standard set of codecs or alternatively
provide transcoding functionality to make sure there is media
interoperability as well. Finally, A-SSP can implement the routing
function enabling traffic shaping and throttling across the
federation.
5.2.1. Assisted PSP Use Case
This is a direct call flow, but with an A-SSP aiding the originating
to terminating domain relationship. The A-SSP may have a relationship
with the originating and/or terminating domain.
1. O-UE initiates a call.
2. The O-SM performs a LUF for next-hop determination of the called
party via the A-LS within the Assisting domain. This can be
done via ENUM/DNS/Redirect 3XX multiple choices and/or static
routing.
3. The resulting CRD will direct the SM to the T-SBE that is
accessible via the O-SBE.
4. Signaling will traverse the O-SM onwards to the O-SBE.
Uzelac (et al.) Expires May 9, 2008 [Page 11]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
5. O-SBE routes call to T-SBE.
6. T-SBE signals T-SM.
7. T-SM signals the called party, T-UE.
8. Bearer path established between O-UE and T-UE through O/A/T DBE.
+------------------------+
| Assist Domain |
| |
| +--------+ |
| | A-LS | |
| ++---+---+ |
| | | |
+---------------+ | | +-----------------+
| Orig Domain \ | | / Term Domain |
| +----------+------+ | / +--------+ |
| / \ | / | LS-t | |
| / +----(3)----+--------+ / +--------+ |
| (2) / \ / |
| / / +------------+ |
|+-----+ +-----+ +-----+ +-----+ |
||O-SM |---(4)--|O-SBE+-----(5)----+T-SBE+---(6)---|T-SM | |
|+-----+ +-----+ +-----+ +-----+ |
| | | | | |
| (1) | (common IP | (7) |
| | |denominator)| | |
| +----+ +-----+ +-----+ +----+ |
| |O-UE+========+O-DBE+=====(8)====+T-DBE+==========+T-UE| |
| +----+ +-----+ +-----+ +----+ |
+----------------------------------------------------------+
Figure 4 Direct with Assisted PSP
PLEASE NOTE – elements depicted are optional.
5.2.2. Assisted SSP (Hub-and-Spoke)
A-SSP serves as the hub for multiple SSPs. Each SSP is the spoke to
the A-SSP which does not need to have direct connections among other
SSPs. To originate a call to a remote number, the SSP will send the
SIP request to the A-SSP. A-SSP is the default peer for all the
numbers that are unknown to the O-SSPs. A-SSP can route the call to
one of its served SSP or to PSTN if A-SSP can’t locate the next-hop
for that call in its own LS. The routing logic in the A-SSP is hidden
to the SSP. Figure 5 shows the high-level network setup.
Uzelac (et al.) Expires May 9, 2008 [Page 12]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
+---------+
| Assisted|
| PSP |
+--+-+-+--+
| | |
| | |
| | |
| | |
| | |
| | |
+----------------+ | +------------------+
| | |
| | |
| | |
| | |
+---+----+ +---+----+ +---+----+
| | | | | |
| SSP1 | | SSP2 | ....... | SSPx |
| | | | | |
+--------+ +--------+ +--------+
Figure 5 Hub-and-Spoke Assisted PSP
6. Federations
This section discusses the federation concept, explains which
technical parameters make up the foundation of a federation and
provides examples.
Contrary to the previous section, this section does not focus on
specific implementation details like the presence of SBCs or other
border elements. The aim here is to provide a broader view on what
kinds of arrangements are possible.
The concrete implementation details (e.g. "direct with one SBC"
versus "direct with two SBCs") can involve all the use cases thus
far described in the document.
6.1. Federation Considerations
Each federation has to specify how a few core operations which are
to be performed by its members.
These include:
1. Peer Discovery
Uzelac (et al.) Expires May 9, 2008 [Page 13]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
This specifies how a SSPs discovers that he can place a specify
call to a peering partner in this federation.
Possible solution are e.g.: a manually configured list of TN-
prefixes and domain names, automatically obtained list of reachable
prefixes/domains by some sort if intra-federation route
announcements, trial queries to the federation's LS, trial lookups
in federation-internal databases (e.g. private DNS),public database
lookups (e.g. I-ENUM).
2. Location Server
What methods are used for TN to URI mapping?
Examples: Public User-ENUM, public Infrastructure ENUM, private
ENUM tree, SIP Redirect, DUNDi.
3. Next Hop Domain Resolution
If the LS 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
The federation 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. Filtering Incoming Calls
On the receiving side, the border element needs to determine
whether the INVITE it just received really came from a member of
the federation. This is the flip side of 4.
Uzelac (et al.) Expires May 9, 2008 [Page 14]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
Example: verify TLS cert, check incoming interface/VLAN,check
source IP address against a configured list of valid ones.
6.2. Federation Examples
This section lists some examples of how federations can operate.
6.2.1. 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 SBC/LS/SBE plus Layer
3infrastructure they need to route and complete the calls.
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.
6.2.2. 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 SBCs 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.
Uzelac (et al.) Expires May 9, 2008 [Page 15]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
6.2.3. 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
federation.
6.2.4. 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,
their associated policies and management make this approach quite
popular today.
This is an example of Assisted Peering.
6.2.4.1. 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
relationships.
Uzelac (et al.) Expires May 9, 2008 [Page 16]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
6.2.5. Private Layer 3 Network
Federations can also establish a separate layer 3 network for their
peering traffic. This could be implemented e.g. by creating a new
VLAN at an Internet exchange point to which all members of that
federation connect their SBEs.
Alternatively, a federation can establish a smaller version of the
Internet to which only members are allowed to connect. The GRX
network of the mobile operators is an example of a dedicated layer
3 infrastructure.
Such a private layer 3 network can also be implemented using
virtual private network (VPN) technologies like IPsec.
In all these cases the SBE can assume that any SIP requests it
receives via an interfaces located in this L3 network comes from
legitimate peering partner.
The separation of the peering network from the Internet makes it
easier to protect the peering arrangement from attacks and to
ensure QoS.
6.2.6. Peer to Peer SIP
P2PSIP replaces the RFC3263 rules by a lookup in a distributed hash
table (DHT). A federation could use this technology to implement
call routing between the peers: the border elements of all members
participate in the DHT algorithm and distribute routing information
this way.
Only members of the federation thus can use information stored in
the DHT which could be the basis of both call routing within the
federation as well as access control between members.
6.2.7. DUNDi
Distributed Universal Number Discovery (DUNDi)
[http://www.dundi.com/dundi.txt] can also be used to build
federations: DUNDi itself acts as a distributed LS which can add
dynamically generated passwords to the URIs it returns.
This way, the T-SBE can verify that an incoming calls comes from a
member of this DUNDi cloud.
Uzelac (et al.) Expires May 9, 2008 [Page 17]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
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
analyzes.
8. IANA Considerations
This document creates no new requirements on IANA namespaces
[RFC2434].
Uzelac (et al.) Expires May 9, 2008 [Page 18]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
References
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 (et al.) Expires May 9, 2008 [Page 19]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 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
Plantronics
Email: rohan@ekabal.com
Yiu L. Lee
Comcast Cable Communications
Email: yiu_lee@cable.comcast.com
David Schwartz
Kayote Networks
Email: david.schwartz@kayote.com
Eli Katz
Xconnect Global Networks
Email: ekatz@xconnect.net
Otmar Lendl
enum.at GmbH
Email: otmar.lendl@enum.at
Uzelac (et al.) Expires May 9, 2008 [Page 20]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Uzelac (et al.) Expires May 9, 2008 [Page 21]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2008
Uzelac (et al.) Expires May 9, 2008 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 11:46:57 |