SPEERMING Working Group A. Uzelac, Ed.
Internet-Draft Global Crossing
Intended status: Informational Y. Lee, Ed.
Expires: November 9, 2008 Comcast Cable
May 8, 2008
VoIP SIP Peering Use Cases
draft-ietf-speermint-voip-consolidated-usecases-07
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2008.
Abstract
This document depicts many common VoIP use case for SIP Peering.
These use cases are categorized into static and on-demand, and then
further sub-categorized into direct and indirect. These use cases
are not an exhaustive set, but rather the most common use cases
deployed today. This document captures them to provide a reference.
Uzelac & Lee Expires November 9, 2008 [Page 1]
Internet-Draft VoIP SIP Peering Use Cases May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 3
4. Contexts of Use Cases . . . . . . . . . . . . . . . . . . . . 4
5. User Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Static Peering Use Cases . . . . . . . . . . . . . . . . . 6
5.1.1. Static Direct Peering Use Case . . . . . . . . . . . . 6
5.1.2. Static Direct Peering Use Case - Assisted LUF and
LRF . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Static Indirect Peering Use Case . . . . . . . . . . . 13
5.1.4. Static Indirect Peering Use Case - Assisted LUF
and LRF . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. On-demand Peering Use Cases . . . . . . . . . . . . . . . 20
5.2.1. On-demand Direct Peering Use Case . . . . . . . . . . 20
6. Federations . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Federation Examples . . . . . . . . . . . . . . . . . . . 21
6.1.1. Trivial Federations . . . . . . . . . . . . . . . . . 21
6.1.2. Access List based Federations . . . . . . . . . . . . 22
6.1.3. Central SIP Proxy Federations . . . . . . . . . . . . 22
6.1.4. Architecture, scalability and business scalability . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security and Privacy Considerations . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Uzelac & Lee Expires November 9, 2008 [Page 2]
Internet-Draft VoIP SIP Peering Use Cases May 2008
1. Introduction
This document attempts to capture VoIP use cases for Session
Initiation Protocol (SIP) [RFC3261] 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 [I-D.lee-speermint-use-case-cable],
[I-D.lendl-speermint-federations],
[I-D.mahy-speermint-direct-peering],
[I-D.schwartz-speermint-use-cases-federations], and
[I-D.uzelac-speermint-use-cases] that have captured use case
scenarios. This draft draws from those documents. 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Reference Architecture
The diagram below provides the reader with a context for the VoIP use
cases in this draft.
Uzelac & Lee Expires November 9, 2008 [Page 3]
Internet-Draft VoIP SIP Peering Use Cases May 2008
+-------------------+-------------------------+-------------------+
| | LUF/LRF Provider Domain | |
| | Indirect SSP Domain | |
| | | |
| | +------+ +------+ | |
| | +A-LUF + + A-LRF| | |
| | +------+ +------+ | |
| | | |
| | +------+ +------+ | |
| | | 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 |
+-----------------------------------------------------------------+
General Overview
Figure 1
PLEASE NOTE: In Figure 1 - the elements defined are optional in many
use cases.
4. Contexts of Use Cases
Use cases are sorted into two general groups: Static and On-demand
Peering [I-D.ietf-speermint-terminology]. Each group can be further
sub-divided to Direct Peering and Indirect Peering
[I-D.ietf-speermint-terminology]. Though there may be some overlap
Uzelac & Lee Expires November 9, 2008 [Page 4]
Internet-Draft VoIP SIP Peering Use Cases May 2008
among the use cases in these categories, there are different
requirements between the scenarios. Each use-case must specify a
basic set of required operations to be performed by each member when
peering.
These can include:
o Peer Discovery - Peer discovery via a Look-Up Function (LUF) to
determine the administrative domain of the target.
o Location Determination - A location determination process serves
to create the Session Establishment Data (SED). Examples: Public
User-ENUM, public Infrastructure ENUM, private ENUM tree, SIP
Redirect, DUNDi.
o Next Hop Determination - A next hop determination based on the SED
is then completed. If Location Routing Function (LRF) 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).
o 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 [RFC3546] to use, and other
authentication schemes.
o Call reception - This step serves to ensure that the type of
relationship (static or on-demand, indirect or direct) is
understood and acceptable. For instance, the receiving side
border elements need to determine whether the INVITE it just
received really came from a member of the federation, possibly via
an access control list entry. This is the flip side of step four.
Example: verify TLS certificate [RFC3546] check incoming
interface/VLAN,check source IP address against a configured list
of valid ones.
Uzelac & Lee Expires November 9, 2008 [Page 5]
Internet-Draft VoIP SIP Peering Use Cases May 2008
5. User 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 [I-D.ietf-speermint-terminology] describes the use
case when two SSPs form a peering relationship with some form of
association established prior to the exchange of traffic. Pre-
association is a prerequisite to static peering. Static peering is
used in cases when two peers want a consistent and tightly controlled
approach to peering. In this scenario, a number of variables, such
as remote proxy IP address and QoS parameters, can be defined upfront
and known by each SSP prior to peering.
5.1.1. Static Direct Peering Use Case
This is the simplest form of a peering use case. Two SSPs negotiate
and agree to establish a SIP peering relationship. The peer
connection is statically configured and is direct between the
connected SSPs. The peers may exchange interconnection parameters
such as DSCP policies, subscriber SIP-URI and proxy location prior to
establishing the interconnection. Typically, they only accept
traffic originating directly from the trusted peer.
Uzelac & Lee Expires November 9, 2008 [Page 6]
Internet-Draft VoIP SIP Peering Use Cases May 2008
+--------------------+ +---------------------+
| O-SSP | | T-SSP |
| +-----+ | | +-----+ |
| |O-LUF| | | |T-LUF| |
| |O-LRF| | | /|T-LRF| |
| /+-----+\ | | / +-----+ |
| (2,3,4) (6) | | / |
| / \ | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(5)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ | | +-----+ |
| | UAC +============+=====(12)====+=============+ UAS | |
| +-----+ | | +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering Use Case
Figure 2
The following is a high-level depiction of the use case:
1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the
home proxy for UAC.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=12345
To: Bob sip+19172223333@example.net;user=phone
Call-ID: abcde@client.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@client.example.com;user=phone
;transport=tcp>
Content-Type: application/sdp
2. O-Proxy checks the domain of the R-URI and discovers that the
UAS's domain is external. So, it queries LUF for SED
information from a routing database. In this example, the LUF
is an ENUM database. The ENUM entry looks similar to this:
Uzelac & Lee Expires November 9, 2008 [Page 7]
Internet-Draft VoIP SIP Peering Use Cases May 2008
$ORIGIN 3.3.3.3.2.2.2.7.1.9.example.net
NATPTR 10 100 "u" "E2U+SIP"
"!^.* !sip:\\1@t-sbe.example.net!"
This SED data can be inputted by O-SSP or populated by the T-SSP
3. Routing database entity replies with SED to called party. In
this example, the SED is DNS NAPTR record. The LRF does a DNS
lookup of the domain name of the NAPTR record and receives a
response similar to this:
;; order perf flags service regxp replacement
IN NAPTR 50 50 "S" "SIPS+D2T" "" _sip._tcp.t-sbe.example.net
IN NAPTR 90 50 "S" "SIPS+D2U" "" _sip._udp.t-sbe.example.net
4. O-Proxy decides to use TCP for transport protocol, so it sends a
DNS query for the SRV record for "_sip._tcp.t-sbe.example.net".
;; priority weight port target
IN SRV 0 1 5060 t-sbe1.example.net
IN SRV 0 2 5060 t-sbe2.example.net
5. Given the O-Proxy's internal routing policy, O-Proxy decides to
use O-SBE to reach T-SBE, so it routes the INVITE request to
O-SBE and adds the route header pointing to T-SBE in the INVITE
request.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:t-sbe1.example.net>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=12345
To: Bob sip+19172223333@example.net;user=phone
Call-ID: abcde@client.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@client.example.com;user=phone
;transport=tcp>
Content-Type: application/sdp
6. O-SBE receives the request and pops the top entry of the Route
header which contains "t-sbe1.example.net". O-SBE sends a DNS
query for "t-sbe1.example.net" to get the A-Record:
Uzelac & Lee Expires November 9, 2008 [Page 8]
Internet-Draft VoIP SIP Peering Use Cases May 2008
;; DNS ANSWER
t-sbe1.example.net A 192.2.0.100
t-sbe1.example.net A 192.2.0.101
7. O-SBE sends the INVITE to T-SBE. O-SBE is the entry point to
the O-SSP domain, so it should ensure subsequent mid-dialog
requests traverse via itself. If O-SBE chooses to act as B2BUA
, it will terminate the call and generate a new back-to-back
INVITE request. If O-SBC chooses to act as proxy, it should
record-route to stay in the call path. In this example, O-SBE
is a B2BUA.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz;
Max-Forwards: 10
Record-Route: <sip:o-sbe1.example.com:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-osbe1@o-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@o-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
8. T-SBE determines called party home proxy and directs call to
called party. T-SBE may use ENUM or other internal mechanism to
locate the home proxy. If T-SSP uses ENUM, this internal ENUM
entry is different from the external ENUM entry populated for
O-SSP. For internal use, it should return the home proxy of
UAS. For external use, it should return T-SBE.
$ORIGIN 3.3.3.3.2.2.2.7.1.9.example.net
NATPTR 10 100 "u" "E2U+SIP"
"!^.* !sip:bob@t-proxy.example.net!"
9. T-SBE receives the NAPTR record and query DNS for the "home-
proxy.example.net". The DNS returns an A-Record:
;; DNS ANSWER
t-proxy.example.net A 192.2.1.2
10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to
UAS's home proxy:
Uzelac & Lee Expires November 9, 2008 [Page 9]
Internet-Draft VoIP SIP Peering Use Cases May 2008
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy;
Max-Forwards: 10
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-tsbe1@t-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@o-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
11. Finally, UAS's home proxy forwards the INVITE request to UAS.
INVITE sip:+19172223333@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111;
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 9
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-tsbe1@t-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@o-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
12. RTP is established between UAC and UAS.
5.1.1.1. 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 typically sign a
peer agreement which state clearly the peering policies and terms.
5.1.1.2. Options and Nuances
In Figure 2. O-SSP and T-SSP peer via SBEs. Normally, the operator
will deploy the SBE in the edge of its administrative domain. The
signaling traffic will pass between two networks through the SBEs.
The operator has many reasons to deploy a SBE. For example, either
Uzelac & Lee Expires November 9, 2008 [Page 10]
Internet-Draft VoIP SIP Peering Use Cases May 2008
proxy and UA may use [RFC1918] addresses that are not routable in the
target network. The SBE can perform a NAT function. Also, the SBE
eases the operation cost for deploying or removing 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 is maintained in the path,
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 Peering Use Case - Assisted LUF and LRF
This use case shares many properties with the static direct use case.
There must exist a pre-association between the O-SSP and T-SSP. The
difference is O-SSP will use the Assisted LUF/LRF Provider for LUF
and LRF. In other words, LUF/LRF provider stores the SED to reach
T-SSP and provides to O-SSP when O-SSP queries it.
Uzelac & Lee Expires November 9, 2008 [Page 11]
Internet-Draft VoIP SIP Peering Use Cases May 2008
+-----------------+
|LUF/LRF Provider |
| |
| +-------+ |
| +-+ A-LUF | |
| / | A-LRF | |
+--------------------+ / ++-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +------------/ (6) | +-----+ |
| / | / | |T-LUF| |
| (2,3,4) +--+ | +-|T-LRF| |
| / / | | / +-----+ |
| / / | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(5)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|0-DBE+=======(12)======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering with Assisted LUF and LRF
Figure 3
The call flow looks almost identical to Static Direct Peering Use
Case except Step 2,3 and 4 which happen in LUF/LRF provider remotely
instead of happening in O-SSP domain.
Note that the media passes through O-DBE and T-DBE in the Figure 3.
This is optional. A DBE may be needed for transcoding or other
traffic policy for media.
5.1.2.1. Administrative Characteristics
The LUF/LRF providers provides the LUF and LRF services for the
O-SSP. As such , LUF/LRF providers, O-SSP and T-SSP form a trusted
administrative domain. To reach T-SSP, O-SSP must still require pre-
arranged assignments for the peer relationship with T-SSP. L5 policy
is maintained in the O-SSP and T-SSP domains, and LUF/LRF provider is
neither unaware nor responsible for L5 policy.
A LUF/LRF provider can serve multiple administrative domains. LUF/
Uzelac & Lee Expires November 9, 2008 [Page 12]
Internet-Draft VoIP SIP Peering Use Cases May 2008
LRF provider must not share SED from one administrative domain to
another administrative domain without appropriate permission granted.
5.1.2.2. Options and Nuances
LRF/LRF provider can use multiple methods to provide SED to O-SSP.
Most commonly used are ENUM query and SIP Redirect. O-SSP should
negotiate with LUF/LRF provider which query method it will use prior
to sending query to LUF/LRF provider.
T-SSP needs to populate its users' SED to LUF/LRF provider.
Currently, this procedure is non-standardized and labor intensive.
IETF is working on this problem and trying to standardize this
procedure for ENUM. [I-D.newton-peppermint-problem-statement] and
[I-D.lewis-peppermint-enum-reg-if] list the problem statements and
requirements.
5.1.3. Static Indirect Peering Use Case
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.3.1. Static Indirect Peering Use Case
Two SSPs negotiate and agree to establish a SIP Peering relation. In
this use case for some reason, they don't have direct L5
connectivity. The reasons may vary, for example business demands
and/or domain policy controls. Due to this indirect relationship the
signalling will traverse from O-SSP to one or multiple I-SSP(s) to
reach T-SSP.
Uzelac & Lee Expires November 9, 2008 [Page 13]
Internet-Draft VoIP SIP Peering Use Cases May 2008
+--------------------+-------------------+---------------------+
| O-SSP | I-SSP | T-SSP |
| +-----+ | | +-----+ |
| -+O-LUF| | | |T-LUF| |
| / |O-LRF+\ | | +----+T-LRF| |
| / +-----+ \ | | / +-----+ |
| /(2,3,4) \(6) | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(5)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=+0-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via I-SSP Domain (SIP and media)
Figure 4
The following is a high-level depiction of the use case:
1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the
home proxy for UAC.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=12345
To: Bob sip+19172223333@example.net;user=phone
Call-ID: abcde@client.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@client.example.com;user=phone
;transport=tcp>
Content-Type: application/sdp
2. O-Proxy checks the domain of the R-URI and discovers that the
UAS's domain is external. So, it queries LUF for SED
information from a routing database. In this example, the LUF
is an ENUM database. The ENUM entry looks similar to this:
$ORIGIN 3.3.3.3.2.2.2.7.1.9.example.net
NATPTR 10 100 "u" "E2U+SIP"
Uzelac & Lee Expires November 9, 2008 [Page 14]
Internet-Draft VoIP SIP Peering Use Cases May 2008
"!^.* !sip:\\1@i-sbe.example.org!"
Note that the response shows the next-hop is the SBE in Indirect
SSP.
Alternatively, O-SSP may have a pre-association with I-SSP. As
such, O-SSP will forward all requests targeting to an external
domain to I-SSP. O-SSP will rely on I-SSP to determine T-SSP
and route the request correctly. In this setup, O-SSP can skip
Steps 2,3,4 and 6 and forward the request to I-SBE. This setup
is commonly used in Enterprise use cases.
3. Routing database entity replies with SED to called party. In
this example, the SED is DNS NAPTR record. The LRF does a DNS
lookup of the domain name of the NAPTR record and receives a
response similar to this:
;; order perf flags service regxp replacement
IN NAPTR 50 50 "S" "SIPS+D2T" "" _sip._tcp.i-sbe.example.org
IN NAPTR 90 50 "S" "SIPS+D2U" "" _sip._udp.i-sbe.example.org
4. O-Proxy decides to use TCP for transport protocol, so it sends a
DNS query for the SRV record for "_sip._tcp.i-sbe.example.org".
;; priority weight port target
IN SRV 0 1 5060 i-sbe1.example.org
IN SRV 0 2 5060 i-sbe2.example.org
5. Given the O-Proxy's internal routing policy, O-Proxy decides to
use O-SBE to reach I-SBE, so it routes the INVITE request to
O-SBE and adds the route header pointing to T-SBE in the INVITE
request.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:i-sbe1.example.org>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=12345
To: Bob sip+19172223333@example.net;user=phone
Call-ID: abcde@client.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@client.example.com;user=phone
;transport=tcp>
Content-Type: application/sdp
Uzelac & Lee Expires November 9, 2008 [Page 15]
Internet-Draft VoIP SIP Peering Use Cases May 2008
6. O-SBE receives the request and pops the top entry of the Route
header which contains "i-sbe1.example.org". O-SBE sends a DNS
query for "i-sbe1.example.org" to get the A-Record:
;; DNS ANSWER
i-sbe1.example.org A 192.3.0.100
i-sbe1.example.org A 192.3.0.101
7. O-SBE sends the INVITE to I-SBE. O-SBE is the entry point to
the O-SSP domain, so it should ensure subsequent mid-dialog
requests traverse via itself. If O-SBE chooses to act as B2BUA,
it will terminate the call and generate a new back-to-back
INVITE request. If O-SBC chooses to act as proxy, it should
record-route to stay in the call path. In this example, O-SBE
is a B2BUA.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz;
Max-Forwards: 10
Record-Route: <sip:o-sbe1.example.com:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-osbe1@o-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@o-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
8. Given the R-URI, I-SBE determines the target belongs to T-SSP.
Since I-SBE is a B2BUA, I-SBE generates a new INVITE request to
T-SSP.
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.com:5060
;branch= z9hG4bK2d4777;
Max-Forwards: 10
Record-Route: <sip:i-sbe1.example.org:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-isbe1@i-sbe1.example.org
CSeq: 1 INVITE
Contact: <sip:+19172223333@i-sbe1.example.org;user=phone
transport=tcp>
Content-Type: application/sdp
Uzelac & Lee Expires November 9, 2008 [Page 16]
Internet-Draft VoIP SIP Peering Use Cases May 2008
Note that I-SSP wants the media to traverse through the I-DBE,
I-SBE must modify the SDP in the Offer to point to its DBE.
9. T-SBE determines called party home proxy and directs call to
called party. T-SBE may use ENUM or other internal mechanism to
locate the home proxy. If T-SSP uses ENUM, this internal ENUM
entry is different from the external ENUM entry populated for
O-SSP. For internal use,it should return the home proxy of UAS.
For external use, it should return T-SBE.
$ORIGIN 3.3.3.3.2.2.2.7.1.9.example.net
NATPTR 10 100 "u" "E2U+SIP"
"!^.* !sip:bob@t-proxy.example.net!"
10. T-SBE receives the NAPTR record and query DNS for the "home-
proxy.example.net". The DNS returns an A-Record:
;; DNS ANSWER
t-proxy.example.net A 192.2.1.2
11. T-SBE sends the INVITE to UAS's home proxy:
INVITE sip:+19172223333@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy;
Max-Forwards: 10
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-tsbe1@t-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@t-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
12. Finally, UAS's home proxy forwards the INVITE request to UAS.
Uzelac & Lee Expires November 9, 2008 [Page 17]
Internet-Draft VoIP SIP Peering Use Cases May 2008
INVITE sip:+19172223333@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111;
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 9
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14083332222@example.com;user=phone>
;tag=54321
To: Bob sip:+19172223333@example.net;user=phone
Call-ID: abcde-tsbe1@t-sbe1.example.com
CSeq: 1 INVITE
Contact: <sip:+19172223333@t-sbe1.example.com;user=phone
transport=tcp>
Content-Type: application/sdp
13. RTP is established between UAC and UAS.
5.1.3.1.1. Administrative characteristics
The Static Indirect Use Case is 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 number portability, Ubiquity of
termination options, security certificate management and masquerading
of originating VoIP network gear.
T-SSP <---> I-SSP = Relationship T-I
In the T-I relationship, typical policies, features or functions
observed consist of codec "scrubbing", anonymizing, and transcoding.
I-SSP must record-route and stay in the signaling path. T-SSP will
not accept message directly sent from O-SSP.
5.1.3.1.2. Options and Nuances
Similar to the Static Direct Peering Use Case, O-SSP and T-SSP may
deploy SBE and DBE for NAT traversal, security, transcoding, etc.
I-SSP can also deploy SBE and DBE for similar reasons. (as depicted
in Figure 4)
Uzelac & Lee Expires November 9, 2008 [Page 18]
Internet-Draft VoIP SIP Peering Use Cases May 2008
5.1.4. Static Indirect Peering Use Case - Assisted LUF and LRF
This use case O-SSP uses LUF/LRF provider for LUF and LRF and I-SSP
to reach T-SSP. LUF/LRF provider and I-SSP can be the same provider
or different providers.
+------------------+
| LUF/LRF Prvoider |
| I-SSP |
| +-------+ |
| ---+ A-LUF | |
| / | A-LRF | |
+--------------------+ / +-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +-------------/ / | +-----+ |
| / | / | |T-LUF| |
| / | (6) | +----+T-LRF| |
| (2,3,4) + +--- | / +-----+ |
| / / | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(5)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=|0-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+-------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via LUR/LRF proivder and I-SSP (SIP and media)
Figure 5
5.1.4.1. Administrative characteristics
The major difference from Static Indirect Peering Use Case, Step
2,3,4 and 6 happen in LUF/LRF provider domain. O-SSP uses this use
case when it uses different I-SSP to reach different T-SSP.
Typically, LUF/LRF provider serves multiple O-SSP. Two O-SSP may use
different I-SSP to reach the same T-SSP. For example, O-SSP1 may use
I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to reach T-SSP. In
other words, given the O-SSP and T-SSP pair as input, LUF/LRF
provider will return the SED of I-SSP that is trusted by O-SSP to
forward the request to T-SSP.
There are two levels of trust relationship. First trust relationship
Uzelac & Lee Expires November 9, 2008 [Page 19]
Internet-Draft VoIP SIP Peering Use Cases May 2008
between O-SSP and LUF/LRF provider. LUF/LRF provider provides LUF
and LRF for O-SSP. Once O-SSP queries the SED, LUF/LRF provider is
out of the picture. Second trust relationship is between O-SSP and
I-SSP. I-SSP provides L5 connectivity to assist O-SSP to reach
T-SSP. O-SSP and I-SSP have a pre-association for policy before
peering happened. Although Figure 5 shows a single provider to
provide both LUR/LRF and I-SSP, O-SSP can choose two different
providers.
5.1.4.2. Options and Nuances
In Figure 5, we show I-DBE. This will be used when O-SSP and T-SSP
do not have a common code. To involve I-DBE, I-SSP should know the
list of codec supported by O-SSP and T-SSP. When I-SBE receives the
INVITE, it will make a decision to invoke the I-DBE. Another
scenario an I-DBE will be used is if O-SSP uses SRTP [RFC3711] for
media and T-SSP does not support SRTP, I-DBE can be used.
5.2. On-demand Peering Use Cases
On-demand Peering [I-D.ietf-speermint-terminology] 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.
5.2.1.1. Administrative characteristics
The On-demand Direct Peering Use Case is typically implemented in a
scenario where the T-SSP allows any O-SSP to reach its serving
subscribers. 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.
5.2.1.2. 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
Uzelac & Lee Expires November 9, 2008 [Page 20]
Internet-Draft VoIP SIP Peering Use Cases May 2008
suffer from the spam problem existing in email system. VoIP spam is
considered more annoying than email spam to the subscribers. T-SSP
should apply rules to filter spam calls.
6. 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.
6.1. Federation Examples
This section lists some examples of how federations can operate.
6.1.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 LUF/LRF/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 peering as conceptually
different to federation-based peering.
On the other extreme, the set of all SSPs implementing an open SIP
service according to [RFC3261], [RFC3263], [RFC3761] 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 Expires November 9, 2008 [Page 21]
Internet-Draft VoIP SIP Peering Use Cases May 2008
6.1.2. Access List based Federations
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.
6.1.3. Central SIP Proxy Federations
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 Indirect Peering.
6.1.4. Architecture, scalability and business scalability
hThe 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.
7. Acknowledgments
This draft is a consolidation of many early individual drafts.
Uzelac & Lee Expires November 9, 2008 [Page 22]
Internet-Draft VoIP SIP Peering Use Cases May 2008
Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David
Schwartz, Eli Katz and Jeremy Barkan are the authors of the early
individal drafts. Besides, Jason Livingood, Daryl Malas, David
Meyer, John Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon
Peterson, Alexander Mayrhofer, and Jean-Francois Mule made many
valuable comments to this draft.
8. Security and Privacy 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.
9. IANA Considerations
This document creates no new requirements on IANA namespaces RFC 2434
[RFC2434].
10. References
10.1. Normative References
[I-D.lee-speermint-use-case-cable]
Lee, Y., "Session Peering Use Case for Cable",
draft-lee-speermint-use-case-cable-01 (work in progress),
September 2006.
[I-D.lendl-speermint-federations]
Lendl, O., "A Federation based VoIP Peering Architecture",
draft-lendl-speermint-federations-03 (work in progress),
September 2006.
[I-D.mahy-speermint-direct-peering]
Mahy, R., "A Minimalist Approach to Direct Peering",
draft-mahy-speermint-direct-peering-02 (work in progress),
July 2007.
[I-D.schwartz-speermint-use-cases-federations]
Schwartz, D., "Session Peering Use Cases for Federations",
draft-schwartz-speermint-use-cases-federations-00 (work in
progress), November 2006.
[I-D.uzelac-speermint-use-cases]
Uzelac & Lee Expires November 9, 2008 [Page 23]
Internet-Draft VoIP SIP Peering Use Cases May 2008
Uzelac, A., "SIP Peering Use Case for VSPs",
draft-uzelac-speermint-use-cases-00 (work in progress),
October 2006.
[I-D.ietf-speermint-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
10.2. Informative References
[I-D.lewis-peppermint-enum-reg-if]
Lewis, E., "ENUM Registry Interface Requirements",
draft-lewis-peppermint-enum-reg-if-01 (work in progress),
November 2007.
[I-D.newton-peppermint-problem-statement]
Newton, A., "Provisioning Extensions in Peering Registries
for Multimedia Interconnection (PEPPERMINT) Problem
Statement", draft-newton-peppermint-problem-statement-00
(work in progress), January 2007.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Uzelac & Lee Expires November 9, 2008 [Page 24]
Internet-Draft VoIP SIP Peering Use Cases May 2008
Extensions", RFC 3546, June 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Authors' Addresses
Adam Uzelac (editor)
Global Crossing
U.S.A.
Phone:
Email: adam.uzelac@globalcrossing.com
URI: http://www.globalcrossing.com
Yiu L.Lee (editor)
Comcast Cable
U.S.A.
Phone:
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Uzelac & Lee Expires November 9, 2008 [Page 25]
Internet-Draft VoIP SIP Peering Use Cases May 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 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.
Uzelac & Lee Expires November 9, 2008 [Page 26]
