One document matched: draft-ietf-speermint-voip-consolidated-usecases-00.txt
Internet Draft A.Uzelac
SPEERMINT Global Crossing
Expires: August 2007 Y.Lee
Comcast
D.Schwartz
Kayote Networks
E. Katz
Xconnect
O.Lendl
enum.at
R.Mahy
Plantronics
March 1, 2007
VoIP SIP Peering Use Cases
draft-ietf-speermint-voip-consolidated-usecases-00.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 September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Uzelac (et al) Expires August 1, 2007 [Page 1]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
Abstract
This document will capture the VoIP use case for SIP Peering. It is
a consolidation of other Speermint use cases and will focus
exclusively on VoIP.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Use Cases......................................................6
3.1. Direct Use Cases..........................................7
3.1.1. Minimalist Direct.......................................7
3.1.2. Direct with one SBE.....................................7
3.1.3. Direct with two SBEs....................................8
3.2. Indirect..................................................9
3.2.1. Transit PSP.............................................9
3.3. Assisted.................................................11
3.3.1. Assisted PSP...........................................11
4. Federations...................................................13
4.1. Federation Categorization................................13
4.2. Federation Examples......................................14
4.2.1. Trivial Federations....................................14
4.2.2. Access List based......................................15
4.2.3. TLS based Federations..................................15
4.2.4. Central SIP Proxy......................................16
4.2.5. Private Layer 3 Network................................16
4.2.6. Peer to Peer SIP.......................................16
4.2.7. DUNDi..................................................17
5. Security Considerations.......................................17
6. IANA Considerations...........................................17
References.......................................................18
Normative References..........................................18
Informative References........................................19
Author's Addresses............................................19
Full Copyright Statement......................................20
Intellectual Property.........................................20
Acknowledgment................................................20
1. Introduction
This document attempts to capture VoIP use cases for Session
Initiation Protocol (SIP)[1] based peering. Identifying use cases
Uzelac (et al.) Expires September 1, 2007 [Page 2]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
will help to understand and clarify requirements. These use cases
will assist in identifying requirements for VoIP Peering using SIP
and provide a perspective on future specifications.
Only use cases related to VoIP such as 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.
Thus, use cases described herein are use cases of VoIP using SIP. 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 complete.
2. Terminology
o Direct Peering: Direct peering describes those cases in which two
service providers interconnect without using an intervening layer
5 network.
o Indirect Peering: Indirect, or transit, peering refers to the
establishment of a secure signaling path 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, so there is no requirement for a trust relationship
directly between the originating and terminating.
o Assisted Peering: In this case, some entity employs a central SIP
proxy (which is not itself a VSP) to facilitate direct calls
between participating networks.
o Federations: A federation is a group of SPs which agree to receive
calls from each other. A Federation may use a Peering Service
Provider, (in any modes Direct, Indirect, Assisted) to facilitate
some or all of the Assisted Peering services.
o Voice Service Provider – (VSP): A Voice Service Provider (or VSP)
is an entity that provides transport of SIP signaling to its
customers. In the event that the VSP is also an SP, it may also
provide media streams to its customers. Such a service provider
may additionally be interconnected with other service providers;
that is, it may "peer" with other service providers. A VSP may
also interconnect with the PSTN.
Uzelac (et al.) Expires September 1, 2007 [Page 3]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
o Originating VSP – (O-VSP): A VSP where the calling party resides.
o Terminating VSP – (T-VSP): A VSP where he called party resides.
o Peering Service Provider – (PSP): A logical entity providing
peering functions.
o Direct PSP – (D-PSP): PSP providing location function or service
enabling direct peering relationship.
o Assisted PSP – (A-PSP): Assisted Peering: In this case, some
entity employs a central SIP proxy (which is not itself a VSP) to
bridge calls between participating networks. Other functions
which may be provided in Assisted Peering include, peering
policies, and administrative rules for such sessions (settlement,
abuse-handling, security requirements) and the specific rules for
the technical details of the interconnection (signaling, media,
layers 1-4 etc.)
o Signaling Border Element: A signaling border element (SBE) [15]
provides signaling-related functions. A SBE is frequently
deployed on a domain's border as a B2BUA.
o Originating SBE (O-SBE): SBE in originating domain.
o Terminating SBE (T-SBE): SBE in terminating domain
o Assisted SBE (A-SBE): SBE in Assisted domain.
o Data Path Border Element: A data path border element (DBE) [15]
provides media-related functions such as deep packet inspection
and modification, media relay, and firewall support under SBE
control. As was the case with the SBE, a DBE is frequently
deployed on a domain's border.
o Originating DBE (O-DBE): The DBE connects to the terminating DBE.
o Terminating DBE (T-DBE): The DBE connects to the originating DBE.
o Assisted DBE (A-DBE): The DBE connects to the originating DBE.
Uzelac (et al.) Expires September 1, 2007 [Page 4]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
o Location Server (LS): A server called upon by VSP-o, either Local
or Remote, to translate an E.164 number into a SIP URI. The VSP-
o's client may call the Location Function using ENUM
Query/Response, SIP Invite/Redirect, or other method depending on
VSP-o's infrastructure and method's 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.
o Session Manager (SM): A SM is the entity responsible for sending
and receiving the SIP messages from or to Signaling Path Border
Element (SBE). It is also responsible for locating the user home
proxy. SM is logical, it MAY contain one functional entity or
multiple functional entities.
o Originating SM (O-SM): The SM originates the call. In this
content, it is Alice's SM.
o Terminating SM (T-SM): The SM terminates the call. In this
content, it is Bob's SM.
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.
o Originating UE (O-UE): Alice's UE.
o Terminating UE (T-UE): Bob's UE.
Uzelac (et al.) Expires September 1, 2007 [Page 5]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
+-------------+-------------------------------------+------------+
| \ Assisted 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 Domain | Terminating Domain |
+----------------------------------------------------------------+
Figure 1 Generalized Overview
PLEASE NOTE: In figure one – the elements defined are option in many
use cases.
3. Use Cases
Use cases are sorted into 3 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.
Per information in the terminology section of this document, the
direct use cases involve those cases in which two service providers
interconnect without using an intervening layer 5 network. This
approach is also considered a bi-lateral peering agreement.
Indirect use cases involve the use of a third party that both the O-
VSP and T-VSP share. This can be considered Transit peering as well.
Uzelac (et al.) Expires September 1, 2007 [Page 6]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
Assisted use case involve the use of a third party, but this third
party may or may not have a pre-existing relationship with the T-VSP.
The A-VSP may only provide next-hop discovery for the O-VSP, or may
be more intimately involved my maintaining session state in both the
signaling and bearer planes.
3.1. Direct Use Cases
3.1.1. Minimalist Direct
1. Off-hook = SIP INVITE
2. O-SM queries for next-hop information from routing database.
3. Routing database entity replies with route to called party
4. Call sent to terminating domains session manager.
5. Session manager sends call to called party.
+------------------+-------------------+
| Orig Domain | Term Domain |
| +--------+ | +--------+ |
| | LS-o | | | LS-t | |
| +--------+ | +--------+ |
| (2) / | |
| /(3) | |
| +-----+ | +-----+ |
| |O-SM |--------(4)---------|T-SM | |
| +-----+ | +-----+ |
| | | | |
| (1) | (5) |
| | | | |
| +----+ | +----+ |
| |O-UE+=======(RTP)=========+T-UE+ |
| +----+ | +----+ |
+------------------+-------------------+
Figure 2 Minimalist Direct
3.1.2. Direct with one SBE
In this type of interconnection scenario, the SBE is owned and
operated within the originating administrative domain.
1. O-UE initiates a call.
Uzelac (et al.) Expires September 1, 2007 [Page 7]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
2. The O-SM performs next-hop determination for the called party
via the LS. This can be done via ENUM/DNS/Redirect 3XX multiple
choices and/or static routing.
3. The result of the query will be O-SBE that is interconnected to
the terminating domain, but administered in the originating
domain.
4. Proxy will signal O-SBE.
5. O-SBE routes call to T-SM within terminating domain.
6. T-SM signals the called party, T-UE.
+------------------+-------------------+
| Orig Domain | Term Domain |
| +--------+ | +--------+ |
| | LS-o | | | LS-t | |
| +--------+ | +--------+ |
| (2) / | |
| /(3) | |
|+-----+ +-----+ +-----+ |
||O-SM |-(4)-|O-SBE+----(5)---|T-SM | |
|+-----+ +--+--+ +-----+ |
| | | | |
| (1) | (6) |
| | | | |
| +----+ | +----+ |
| |O-UE+=========(RTP)=========+T-UE+ |
| +----+ | +----+ |
+------------------+-------------------+
Figure 3 Direct with one SBEs
3.1.3. Direct with two SBEs
Multiple SBCs are implemented in this interconnection scenario. The
SBEs are operated within different administrative domains.
1. O-UE initiates a call.
2. The O-SM performs next-hop determination for the called party
via the LS. This can be done via ENUM/DNS/Redirect 3XX multiple
choices and/or static routing.
3. The result of the query will be O-SBE that is interconnected to
the terminating domain, but administered in the originating
domain.
Uzelac (et al.) Expires September 1, 2007 [Page 8]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
4. Proxy will signal O-SBE.
5. O-SBE routes call to T-SBE within terminating domain.
6. T-SBE signals T-SM.
7. T-SM signals the called party, T-UE.
+---------------------+ +-----------------------+
| Orig Domain | | Term Domain |
| +--------+ | | +--------+ |
| | LS-o | | | | LS-t | |
| +--------+ | | +--------+ |
| (2) / | | |
| /(3) | | |
|+-----+ +-----+ +-----+ +-----+ |
||O-SM |---(4)--|O-SBE|--(5)--|T-SBE+---(6)---|T-SM | |
|+-----+ +-----+ +-----+ +-----+ |
| | | | | |
| (1) | | (7) |
| | | | | |
| +----+ +-----+ +-----+ +----+ |
| |O-UE+========+O-DBE+=======+T-DBE+==========+O-UE| |
| +----+ +-----+ +-----+ +----+ |
+---------------------+ +-----------------------+
Figure 4 Direct with two SBEs
3.2. Indirect
3.2.1. Transit PSP
This is a direct call flow, as in the minimalist approach, but with a
PSP aiding the originating domain.
1. O-UE initiates a call.
2. The O-SM performs next-hop determination for the called party
via the LS within the Assisted domain. This can be done via
ENUM/DNS/Redirect 3XX multiple choices and/or static routing.
3. The result of the query will be A-SBE that is interconnected to
the Transit domain, but administered in the originating domain.
4. O-SM will signal A-SBE.
5. O-SBE routes call to T-SBE within terminating domain.
Uzelac (et al.) Expires September 1, 2007 [Page 9]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
6. T-SBE signals T-SM.
T-SM signals the called party, T-UE.
+------------------+
| Assist Domain +
| |
| +--------+ |
| +--+ LS-a | |
| / +-+--------+ |
| / / |
+---------------+ / / +----------------------+
| Orig Domain |/ / | Term Domain |
| +--------+ / | +--------+ |
| / |/ | | LS-t | |
| / +----(3)+ | +--------+ |
| (2) / | | |
| / / | | |
|+-----+ +-----+ +-----+ +-----+|
||O-SM |---(4)--|A-SBE+------------+T-SBE+---(6)---|T-SM ||
|+-----+ +-----+ +-----+ +-----+|
| | | | | | | |
| (1) | | | | (7) |
| | | | | | | |
| +----+ +-----+ +-----+ +----+|
| |O-UE+========+A-DBE+============+T-DBE+==========+O-UE||
| +----+ +-----+ +-----+ +----+|
+---------------------------------------------------------+
Figure 5 Indirect with Assisted PSP
1. The proxy within the originating domain performs some next-hop
determination for the called party. This can be done via
ENUM/DNS/Redirect 3XX multiple choices and/or static routing.
2. The next-hop would be one of possibly many SBCs that border with
VSP(T), but is owned and operated by VSP(o).
3. The proxy in VSP(o) signals SBC1
4. SBC1 performs some next-hop determination for the called party.
This can be done via ENUM/DNS/Redirect 3XX multiple choices
and/or static routing. This process occurs within VSP(T).
5. The result of this query would be SBC2 that is also under the
administrative responsibility of VSP(T).
Uzelac (et al.) Expires September 1, 2007 [Page 10]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
6. SBC1 signals SBC2.
7. Another separate next-hop route determination process will occur
within VSP(t).
8. The result is the terminating proxy.
9. SBC2 signals terminating proxy.
3.3. Assisted
Assisted use cases involve the facilitation of direct session
establishment between the O-VSP and T-VSP. There may exist elements
that provide SIP proxy functionality, and are often implemented in
practice by SBE’s which may "filter" "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-PSP. As an external element, A-PSP can
provide the full set of services for VSPs, and through its own
relationships with the VSP, eliminate the need of all VSPs for pair-
wise service relationships. A-PSP can potentially encompass a large
namespace of users that is accessible in one query to external VSP
members (or not -depending on policy).
In addition there is an interoperability function usually performed
by an SBE, almost guaranteeing interoperability and protocol
interchangeability between member VSPs. 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-PSP can implement the routing
function enabling traffic shaping and throttling across the
federation.
3.3.1. Assisted PSP
This is a direct call flow, as in the minimalist approach, but with a
PSP aiding the originating domain.
1. O-UE initiates a call.
Uzelac (et al.) Expires September 1, 2007 [Page 11]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
2. The O-SM performs next-hop determination for the called party
via the LS within the Assisted domain. This can be done via
ENUM/DNS/Redirect 3XX multiple choices and/or static routing.
3. The result of the query will be O-SBE that is interconnected to
the terminating domain, but administered in the originating
domain.
4. Proxy will signal O-SBE.
5. O-SBE routes call to T-SBE within terminating domain.
6. T-SBE signals T-SM.
7. T-SM signals the called party, T-UE.
+------------------------+
| Assist Domain |
| |
| +--------+ |
| | LS-a | |
| ++---+---+ |
| | | |
+---------------+ | | +-----------------+
| Orig Domain \ | | / Term Domain |
| +----------+------+ | / +--------+ |
| / \ | / | LS-t | |
| / +----(3)----+--------+ / +--------+ |
| (2) / \ / |
| / / +------------+ |
|+-----+ +-----+ +-----+ +-----+ +-----+ |
||O-SM |---(4)--|O-SBE+--|A-SBE+---+T-SBE+---(6)---|T-SM | |
|+-----+ +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| (1) | | (7) |
| | | | | |
| +----+ +-----+ +-----+ +-----+ +----+ |
| |O-UE+========+O-DBE+==+A-DBE+===+T-DBE+==========+O-UE| |
| +----+ +-----+ +-----+ +-----+ +----+ |
+----------------------------------------------------------+
Figure 6 Direct with Assisted PSP
PLEASE NOTE – elements depicted are optional.
Uzelac (et al.) Expires September 1, 2007 [Page 12]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
4. 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") is often orthogonal to this list. To
recapitulate: A federation is a group of VSPs which agree to
receive calls from each other using pre-agreed technical and
administrative procedures.
4.1. Federation Categorization
The technical procedures which federations need to define can be
used to categorize them. Each federation has to specify how a few
core operations which are to be performed by its members.
These include:
1. Peer Discovery
This specifies how a VSPs 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
Uzelac (et al.) Expires September 1, 2007 [Page 13]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
If the LS did not return an URI of the form sip:user@IP-address,
then the originating VSP 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.
Example: verify TLS cert, check incoming interface/VLAN,check
source IP address against a configured list of valid ones.
4.2. Federation Examples
This section lists some examples of how federations can operate.
4.2.1. Trivial Federations
A private peering arrangement between two VSPs is a special case of
a federation. These two VSP 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 VSPs 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
Uzelac (et al.) Expires September 1, 2007 [Page 14]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
contained in these three RFCs, the LS is the public DNS. Whether
some of these VSPs 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.
4.2.2. Access List based
If running an open SIP proxy is not desired, then a group of VSPs
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 VSPs 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 VSP needs to
adapt its filter rules.
4.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 VSP. Thus
the ingress element of a VSP 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 VSP joins that
federation.
Uzelac (et al.) Expires September 1, 2007 [Page 15]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
4.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 VSP
just triggers a change in the configuration of this box and not at
all other VSPs.
Although such a setup reduces the configuration complexity of
larger federations, the central SIP proxy might lead to other
scaling issues.
This is an example of Assisted Peering.
4.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.
4.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.
Uzelac (et al.) Expires September 1, 2007 [Page 16]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
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.
4.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.
5. 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.
6. IANA Considerations
This document creates no new requirements on IANA namespaces
[RFC2434].
Uzelac (et al.) Expires September 1, 2007 [Page 17]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
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 September 1, 2007 [Page 18]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
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 September 1, 2007 [Page 19]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
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 September 1, 2007 [Page 20]
Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007
Uzelac (et al.) Expires September 1, 2007 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 00:12:15 |