SPEERMING Working Group A. Uzelac, Ed.
Internet-Draft Global Crossing
Intended status: Informational Y. Lee, Ed.
Expires: October 30, 2010 Comcast Cable
April 28, 2010
VoIP SIP Peering Use Casesdraft-ietf-speermint-voip-consolidated-usecases-18
Abstract
This document depicts many common Voice over IP (VoIP) use cases for
Session Initiation Protocol (SIP) Peering. These use cases are
categorized into static and on-demand, and then further sub-
categorized into direct and indirect. These use cases are not an
exhaustive set, but rather the most common use cases deployed today.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 30, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Uzelac & Lee Expires October 30, 2010 [Page 1]

Internet-Draft VoIP SIP Peering Use Cases April 20101. Introduction
This document describes important Voice over IP (VoIP) use cases
Session Initiation Protocol (SIP) [RFC3261] based peering. These use
cases are determined by the SPEERMINT working group and will assist
in identifying requirements and other issues to be considered for
future resolution by the working group.
Only use cases related to VoIP are considered in this document.
Other real-time SIP communications use cases, like Instant Messaging
(IM), Video Chat, and Presence are out of scope for this document.
The use cases contained in this document are described as
comprehensive as possible, but should not be considered the exclusive
set of use cases.
2. Terminology
This document uses terms defined in [RFC5486]. Please refer to it
for definitions.
3. Reference Architecture
The diagram below provides the reader with a context for the VoIP use
cases in this document. Terms such as SIP Service Provider (SSP),
Look-Up Function (LUF), Location Routing Function (LRF), Signaling
Path Border Element (SBE) and Data Path Border Element (DBE) are
defined in [RFC5486].
Originating SSP (O-SSP) is the SSP originating a SIP request.
Terminating SSP (T-SSP) is the SSP terminating the SIP request
originating from O-SSP. Assisting LUF and LRF Provider offers LUF
and LRF services to O-SSP. Indirect SSP (I-SSP) is the SSP providing
indirect peering service(s) to O-SSP to connect to T-SSP.
Uzelac & Lee Expires October 30, 2010 [Page 3]

Internet-Draft VoIP SIP Peering Use Cases April 2010
hop address.
o Call setup - SSPs that are interconnecting to one another may also
define specifics on what peering policies need to be used when
contacting the next hop in order to a) reach the next hop at all
and b) 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 Layer-3
network), which TLS client certificate [RFC5246] 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 example, the receiving SBE needs
to determine whether the INVITE it received really came from a
trusted member.
5. Use Cases
Please note there are intra-domain message flows within the use cases
to serve as supporting background information. Only inter-domain
communications are germane to this document.
5.1. Static Peering Use Cases
Static Peering [RFC5486] describes the use case when two SSPs form a
peering relationship with some form of association established prior
to the exchange of traffic. Pre-association is a prerequisite to
static peering. Static peering is used in cases when two peers want
a consistent and tightly controlled approach to peering. In this
scenario, a number of variables, such as an identification method
(remote proxy IP address) and Quality of Service (QoS) parameters,
can be defined upfront and known by each SSP prior to peering.
5.2. Static Direct Peering Use Case
This is the simplest form of a peering use case. Two SSPs negotiate
and agree to establish a SIP peering relationship. The peer
connection is statically configured and the peer SSPs are directly
connected. The peers may exchange interconnection parameters such as
DSCP [RFC2474] policies, the maximum number of requests per second,
and proxy location prior to establishing the interconnection.
Typically, the T-SSP only accepts traffic originating directly from
the trusted peer.
Uzelac & Lee Expires October 30, 2010 [Page 5]

Internet-Draft VoIP SIP Peering Use Cases April 2010
2. UAC knows UAS's TN, but does not know UAS's domain. It appends
its own domain to generate the SIP URI in Request-URI and TO
header. O-Proxy checks the Request-URI and discovers that the
Request-URI contains user parameter "user=phone". This
parameter signifies that the Request-URI is a phone number. So
O-Proxy will extract the TN from the Request-URI and query LUF
for SED information from a routing database. In this example,
the LUF is an ENUM [RFC3761] database. The ENUM entry looks
similar to this:
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@example.net!"
. )
This SED data can be provisioned by O-SSP or populated by the
T-SSP.
3. O-Proxy examines the SED and discovers the domain is external.
Given the O-Proxy's internal routing policy, O-Proxy decides to
use O-SBE to reach T-SBE. O-Proxy routes the INVITE request to
O-SBE and adds a Route header which contains O-SBE.
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
4. O-SBE receives the requests and pops the top entry of the Route
header which contains "o-sbe1.example.com". O-SBE examines the
Request-URI and does a LRF for "example.net". In this example,
Uzelac & Lee Expires October 30, 2010 [Page 7]

Internet-Draft VoIP SIP Peering Use Cases April 2010
the LRF is a NAPTR DNS query [RFC3403] of the domain name.
O-SBE receives a NAPTR response from LRF. The response looks
similar to this:
IN NAPTR (
50
50
"S"
"SIP+D2T"
""
_sip._tcp.t-sbe.example.net. )
IN NAPTR (
90
50
"S"
"SIP+D2U"
""
_sip._udp.t-sbe.example.net. )
5. Given the lower order for TCP in the NAPTR response, O-SBE
decides to use TCP as the transport protocol, so it sends a SRV
DNS query for the SRV record [RFC2782] for "_sip._tcp.t-
sbe.example.net." to O-LRF.
;; priority weight port target
IN SRV 0 2 5060 t-sbe1.example.net.
IN SRV 0 1 5060 t-sbe2.example.net.
6. Given the higher weight for "t-sbe1.example.net", O-SBE sends an
A record DNS query for "t-sbe1.example.net." to get the A
record:
;; DNS ANSWER
t-sbe1.example.net. IN A 192.0.2.100
t-sbe1.example.net. IN A 192.0.2.101
7. O-SBE sends the INVITE to T-SBE. O-SBE is the egress point to
the O-SSP domain, so it should ensure subsequent mid-dialog
requests traverse via itself. If O-SBE chooses to act as a
Back-to-Back User Agent (B2BUA) [RFC3261], it will generate a
new INVITE request in next step. If O-SBE chooses to act as a
proxy, it should record-route to stay in the call path. In this
example, O-SBE is a B2BUA.
Uzelac & Lee Expires October 30, 2010 [Page 8]

Internet-Draft VoIP SIP Peering Use Cases April 2010
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
Note that O-SBE may re-write the Request-URI with the target
domain in the SIP URI. Some proxy implementations will only
accept the request if the Request-URI contains their own
domains.
8. T-SBE determines the called party home proxy and directs the
call to the called party. T-SBE may use ENUM lookup or other
internal mechanism to locate the home proxy. If T-SSP uses ENUM
lookup, this internal ENUM entry is different from the external
ENUM entry populated for O-SSP. In this example, the internal
ENUM query returns the UAS's home proxy.
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@t-proxy.example.net!"
. )
9. T-SBE receives the NAPTR record and following the requirements
in [RFC3263] queries DNS for the SRV records indicated by the
NAPTR result. Not finding any, the T-SBE then queries DNS for
the A record of domain "t-proxy.example.net.".
;; DNS ANSWER
t-proxy.example.net. IN A 192.0.2.2
10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to
UAS's home proxy:
Uzelac & Lee Expires October 30, 2010 [Page 9]

Internet-Draft VoIP SIP Peering Use Cases April 20105.2.2. Options and Nuances
In Figure 2 O-SSP and T-SSP peer via SBEs. Normally, the operator
will deploy the SBE at the edge of its administrative domain. The
signaling traffic will pass between two networks through the SBEs.
The operator has many reasons to deploy a SBE. For example, the
O-SSP may use [RFC1918] addresses for their UA and proxies. These
addresses are not routable in the target network. The SBE can
perform a NAT function. Also, the SBE eases the operation cost for
deploying or removing Layer-5 network elements. Consider the
deployment architecture where multiple proxies connect to a single
SBE. An operator can add or remove a proxy without coordinating with
the peer operator. The peer operator "sees" only the SBE. As long
as the SBE is maintained in the path, the peer operator does not need
to be notified.
When an operator deploys SBEs, the operator is required to advertise
the SBE to the peer LRF so that the peer operator can locate the SBE
and route the traffic to the SBE accordingly.
SBE deployment is a decision within an administrative domain. Either
one or both administrative domains can decide to deploy SBE(s). To
the peer network, most important is to identify the next-hop address.
This decision does not affect the network's ability to identify the
next-hop address.
5.3. Static Direct Peering Use Case - Assisting LUF and LRF
This use case shares many properties with the Static Direct Peering
Use Case. There must exist a pre-association between the O-SSP and
T-SSP. The difference is O-SSP will use the Assisting LUF/LRF
Provider for LUF and LRF. The LUF/LRF provider stores the SED to
reach T-SSP and provides it to O-SSP when O-SSP requests it.
Uzelac & Lee Expires October 30, 2010 [Page 11]

Internet-Draft VoIP SIP Peering Use Cases April 2010
LUF/LRF provider typically does not share SED from one administrative
domain to another administrative domain without appropriate
permission.
5.3.2. Options and Nuances
The LUF/LRF provider can use multiple methods to provide SED to
O-SSP. The most commonly used are an ENUM lookup and a SIP Redirect.
The O-SSP should negotiate with the LUF/LRF provider which query
method it will use prior to sending request to LUF/LRF provider.
The LUF/LRF providers must be populated with the T-SSP's AORs and
SED. Currently, this procedure is non-standardized and labor
intensive. A more detailed description of this problem has been
documented in the work in progress
[I-D.ietf-drinks-usecases-requirements].
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF
The difference between a Static Direct Use Case and a Static Indirect
Use Case lies within the Layer-5 relationship maintained by O-SSP and
T-SSP. In the Indirect use case, the O-SSP and T-SSP do not have
direct Layer-5 connectivity. They require one or multiple Indirect
Domains to assist routing the SIP messages and possibly the
associated media.
In this use case, the O-SSP and T-SSP want to form a peer
relationship. For some reason, the O-SSP and T-SSP do not have
direct Layer-5 connectivity. The reasons may vary, for example
business demands and/or domain policy controls. Due to this indirect
relationship the signaling will traverse from O-SSP through one or
multiple I-SSP(s) to reach T-SSP.
In addition, O-SSP is using a LUF/LRF provider. This LUF/LRF
provider stores the T-SSP's SED pre-populated by T-SSP. One
important motivation to use the LUF/LRF provider is that T-SSP only
needs to populate its SED once to the provider. Using LUF/LRF
provider allows the T-SSP to populate its SED once, while any O-SSP
T-SSP's SED can use this LUF/LRF provider. Current practice has
shown that it is rather difficult for the T-SSP to populate its SED
to every O-SSP who must reach the T-SSP's subscribers. This is
especially true in the Enterprise environment.
Note that the LUF/LRF provider and I-SSP can be the same provider or
different providers.
Uzelac & Lee Expires October 30, 2010 [Page 13]

Internet-Draft VoIP SIP Peering Use Cases April 2010
2. UAC knows UAS's TN, but does not know UAS's domain. It appends
its own domain to generate the SIP URI in Request-URI and TO
header. O-Proxy checks the Request-URI and discovers that the
Request-URI contains user parameter "user=phone". This
parameter indicates that the Request-URI is a phone number. So
O-Proxy will extract the TN from the Request-URI and query LUF
for SED information from a routing database. In this example,
the LUF is an ENUM database. The ENUM entry looks similar to
this:
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@example.org!"
. )
Note that the response shows the next-hop is the SBE in I-SSP.
Alternatively, O-SSP may have a pre-association with I-SSP. As
such, O-SSP will forward all requests which contains an external
domain in the Request-URI or unknown TN to I-SSP. The O-SSP
will rely on the I-SSP to determine the T-SSP and route the
request correctly. In this configuration, the O-SSP can skip
Steps 2,4,5 and 6 and forward the request directly to the I-SBE.
This configuration is commonly used in the Enterprise
environment.
3. Given the O-Proxy's internal routing policy, O-Proxy decides to
use O-SBE to reach I-SBE. O-Proxy routes the INVITE request to
O-SBE and adds a Route header which contains the O-SBE.
Uzelac & Lee Expires October 30, 2010 [Page 15]

Internet-Draft VoIP SIP Peering Use Cases April 2010
6. Given the higher weight for "i-sbe1.example.org", O-SBE sends a
DNS query for A record of "i-sbe1.example.org." to get the A
record:
;; DNS ANSWER
i-sbe1.example.org. IN A 192.0.2.200
i-sbe1.example.org. IN A 192.0.2.201
7. 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 a
B2BUA, it will generate a new back-to-back INVITE request in
next step. If O-SBE 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:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
Route: <sip:i-sbe1.example.org;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
8. I-SBE receives the request and queries its internal routing
database on the TN. It determines the target belongs to T-SSP.
Since I-SBE is a B2BUA, I-SBE generates a new INVITE request to
T-SSP.
Uzelac & Lee Expires October 30, 2010 [Page 17]

Internet-Draft VoIP SIP Peering Use Cases April 2010
INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.org:5060
;branch= z9hG4bK2d4777
Max-Forwards: 7
Route: <sip:t-sbe1.example.net;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-isbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
transport=tcp>
</allOneLine>
Note that if 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 the called party home proxy and directs the
call to the called party. T-SBE may use ENUM lookup or other
internal mechanism to locate the home proxy. If T-SSP uses ENUM
lookup, this internal ENUM entry is different from the external
ENUM entry populated for O-SSP. This internal ENUM entry will
contain the information to identify the next-hop to reach the
called party. In this example, the internal ENUM query returns
the UAS's home proxy.
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa.
IN NAPTR (
10
100
"u"
"E2U+SIP"
"!^.*$!sip:+19175550100@t-proxy.example.net!"
. )
Note that this step is optional. If T-SBE has other ways to
locate the UAS home proxy, T-SBE can skip this step and send the
request to the UAS's home proxy. We show this step to
illustrate one of the many possible ways to locate UAS's home
proxy.
10. T-SBE receives the NAPTR record and following the requirements
in [RFC3263] queries DNS for the SRV records indicated by the
NAPTR result. Not finding any, the T-SBE then queries DNS for
the A record of domain "t-proxy.example.net.".
Uzelac & Lee Expires October 30, 2010 [Page 18]

Internet-Draft VoIP SIP Peering Use Cases April 2010
T-SSP indirectly via I-SSP.
Typically, a LUF/LRF provider serves multiple O-SSPs. Two O-SSPs 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.
Given the O-SSP and T-SSP pair as input, the LUF/LRF provider will
return the SED of I-SSP that is trusted by O-SSP to forward the
request to T-SSP.
In this use case. there are two levels of trust relationship. First
trust relationship is between the O-SSP and LUF/LRF provider. The
O-SSP trusts the LUF/LRF to provide the T-SSP's SED. Second trust
relationship is between O-SSP and I-SSP. The O-SSP trusts the I-SSP
to provide Layer-5 connectivity to assist the O-SSP to reach T-SSP.
The O-SSP and I-SSP have a pre-arranged agreement for policy. Note
that Figure 4 shows a single provider to provide both LUF/LRF and
I-SSP, but O-SSP can choose two different providers.
5.4.2. Options and Nuances
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP
may deploy SBE and DBE for NAT traversal, security, transcoding, etc.
I-SSP can also deploy SBE and DBE for similar reasons. (as depicted
in Figure 4)
5.5. Static Indirect Peering Use Case
This use case shares many properties with the Static Indirect Use
Case with Assisting LUF and LRF. The difference is that the O-SSP
uses its internal LUF/LRF to control the routing database. By
controlling the database, O-SSP can apply different routing rules and
policies to different T-SSPs. For example, O-SSP can use I-SSP1 and
Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach
T-SSP2. Note that there could be multiple I-SSPs and multiple SIP
routes to reach the same T-SSP; the selection process is out of scope
of this document.
Uzelac & Lee Expires October 30, 2010 [Page 20]

Internet-Draft VoIP SIP Peering Use Cases April 2010
common codec. To involve I-DBE, I-SSP should know the list of codecs
supported by O-SSP and T-SSP. When I-SBE receives the INVITE
request, it will make a decision to invoke the I-DBE. An I-DBE may
also be used if O-SSP uses SRTP [RFC3711] for media and T-SSP does
not support SRTP.
5.6. On-demand Peering Use Case
On-demand Peering [RFC5486] describes how two SSPs form the peering
relationship without a pre-arranged agreement.
The basis of this use case is built on the fact that there is no pre-
established relationship between the O-SSP and T-SSP. The O-SSP and
T-SSP does not share any information prior to the dialog initiation
request. When the O-Proxy invokes the LUF and LRF on the Request-
URI, the terminating user information must be publicly available.
When the O-Proxy routes the request to the T-Proxy, the T-Proxy must
accept the request without any pre-arranged agreement with O-SSP.
The On-demand Peering Use Case is uncommon in production. In this
memo, we capture only the high-level descriptions. Further analysis
is expected when this use case becomes more popular.
5.6.1. Administrative characteristics
The On-demand Direct Peering Use Case is typically implemented in a
scenario where the T-SSP allows any O-SSP to reach its serving
subscribers. T-SSP administrative domain does not require any pre-
arranged agreement to accept the call. The T-SSP makes its
subscribers information publicly available. This model mimics the
Internet email model. Sender does not need an pre-arranged agreement
to send email to the receiver.
5.6.2. Options and Nuances
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP
can decide to deploy SBE. Since T-SSP is open to the public, T-SSP
is considered to be in higher security risk than static model because
there is no trusted relationship between O-SSP and T-SSP. T-SSP
should protect itself from any attack launched by untrusted O-SSP.
6. Acknowledgments
Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David
Schwartz, Eli Katz and Jeremy Barkan are the authors of the early
individual drafts. Their use cases are captured in this document.
Besides, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan,
Uzelac & Lee Expires October 30, 2010 [Page 22]