◆ IMS Network Signaling Peering:

Challenges and Proposal

Jean-Philippe Joseph

IP Multimedia Subsystem (IMS) network peering is a key enabler that will

help accelerate deployment of next-generation IMS-based networks. Today’s
early deployments of dispersed IMS networks require public switched
telephone network (PSTN)/public land mobile network (PLMN) bridges for
network interconnection between IMS islands. The PSTN/PLMN bridging
arrangement is inefficient, however, in that it results in unnecessary
settlements for the carriers. It further impedes the implementation of rich
multimedia and Voice over IP (VoIP)-related services that require end-to-end
Internet Protocol (IP) connectivity. Last, it perpetuates the reliance on the
existing PSTN/PLMN network for voice calls among subscribers served by
different IMS-based carriers. This paper analyzes in detail the IMS peering
challenges from the perspective of Session Initiation Protocol (SIP) signaling
peering. It discusses issues related to the routing of SIP messages, and
addressing, address resolution, and discovery of peering points for IMS
signaling peering. It further establishes that a new routing algorithm is
needed that will allow signaling peering points to dynamically discover the
“best” transit network among others for reaching a destination. In closing,
it presents a high-level IMS signaling routing process that includes, among
other benefits, support for number portability as a key function for
inter-carrier IMS peering. © 2008 Alcatel-Lucent.

Introduction
Globally, many service providers (SP), wireline
and wireless alike, are planning or already starting
to deploy next-generation IP Multimedia Subsystem
(IMS) [1] networks to evolve from the embedded
base public switched telephone network (PSTN). The
IMS networks will, among other things, support rich
and robust multimedia services including Voice over
Internet Protocol (VoIP) and, hence, enhance user
experience.
These initial IMS networks, however, are being
deployed in islands with no direct interconnections
among themselves. For instance, for narrowband
voice, IMS networks essentially rely on the PSTN to
route voice calls among the IMS islands. That is, calls
among IMS subscribers served by different SPs are
most likely routed through the PSTN, resulting in less
efficient routing, an inability to support end-to-end
VoIP related services (e.g., wideband voice), unnec-
essary settlements, and the undesirable impact of
perpetuating the PSTN.
Various standards organizations have recently
begun to tackle crucial aspects of IMS peering,
including policy, signaling, network, and security
peering. The International Telecommunication Union,

Bell Labs Technical Journal 12(4), 33–48 (2008) © 2008 Alcatel-Lucent. Published by Wiley Periodicals, Inc. Published
online in Wiley InterScience (www.interscience.wiley.com) • DOI: 10.1002/bltj.20265
 Panel 1. Abbreviations, Acronyms, and Terms
3GPP—3rd Generation Partnership Project
AAA—Authentication, authorization and
accounting
BGCF—Breakout gateway control function
BGP—Border Gateway Protocol
CdP—Called party
CSCF—Call session control function
DDDS—Dynamic delegation discovery system
DNS—Domain name system
E2U—E.164 to URI Resolution
ENUM—Electronic number mapping
GPRS—General packet radio service
GRX—GPRS roaming exchange
GSM—Global System for Mobile
Communications
HSS—Home subscriber server
IBCF—Interworking border control function
I-CSCF—Interrogating CSCF
IETF—Internet Engineering Task Force
IMS—IP Multimedia Subsystem
IN—Intelligent network
IP—Internet Protocol
ISDN—Integrated services digital network
ISP—Internet service provider
ISUP—ISDN user part
ITU—International Telecommunication Union
ITU-T—ITU Telecommunication Standardization
Sector
LD—Long distance
LERG—Local exchange routing guide
LF—Location function
LIA—Location-info-answer
LIR—Location-info-request
LRN—Location routing number
MGCF—Media gateway control function
NAI—Network access identifier
NAPTR—Naming authority pointer
NG—Next-generation
NGN—Next-generation network
Telecommunication Standardization Sector (ITU-T)
next-generation network (NGN) defined resource
and admission control functions (RACF) require-
ments [15] for effective resource management in the
transport layer. The Internet Engineering Task Force
(IETF) recently created the Session Peering for
Multimedia Interworking (SPEERMINT) working
group to define a framework for layer 5 peering
34 Bell Labs Technical Journal DOI: 10.1002/bltj
NP—Number portability
NPA—Numbering plan area
NPDB—Number portability database
OPEX—Operational expenditures
PbUI—Public user identity
P-CSCF—Proxy CSCF
PDA—Personal digital assistant
PF—Policy function
PLMN—Public land mobile network
PP—Peering point
PrUI—Private user identity
PSTN—Public switched telephone network
QoS—Quality of service
RACF—Resource and admission control function
RFC—Request for comments
S-CSCF—Serving CSCF
SCTP—Stream Control Transmission Protocol
SF—Signaling function
SIP—Session Initiation Protocol
SLA—Service level agreements
SLF—Subscriber location function
SM—Session manager
SP—Service provider
SPEERMINT—Session Peering for Multimedia
Interworking
SPNP—Service provider number portability
SRV—Service record
SS7—Signaling System 7
TAS—Telephony application server
TCP—Transport Control Protocol
TEL—Telephone
THIG—Topology hiding interface gateway
TLS—Transport layer security
UA—User agent
UDP—User Datagram Protocol
URI—Uniform resource identifier
VoIP—Voice over IP
VPN—Virtual private network
[18, 20]. The 3rd Generation Partnership Project
(3GPP*) defines in Release 7 (R7) a new signaling
peering entity: the interworking border control func-
tion (IBCF) [2]. The GSM Association (GSMA) defined
guidelines for IMS roaming and interworking [10].
The European Telecommunications Standards Institute
(ETSI) addressed issues related to interconnection
and routing, and their implications on numbering,
naming, and addressing for NGN Telecommunication
and Internet Converged Services and Protocols for
Advanced Networks (TISPAN) [6]. The content of this
paper reflects the work conducted, thus far, by these
organizations.
This paper analyzes in detail the IMS peering
challenges from the perspective of Session Initiation
Protocol (SIP) signaling peering. It focuses primarily
on voice applications and delves into other critical
networking issues that further complicate the discov-
ery of signaling peering points for inter-carrier rout-
ing. Finally, it presents a high-level signaling routing
process for IMS signaling routing that includes sup-
port for number portability as a key function for inter-
carrier IMS peering, and identifies key areas for
further investigation.
The paper is organized as follows: We first pro-
vide background material on why the PSTN is used
today for IMS network interconnection and the
impacts of PSTN bridging. Next, we describe a generic
case of IMS peering to discuss the critical issues
related to address resolution and discovery of peer-
ing points. We follow by presenting other factors—
such as inter-domain IP infrastructure, identification,
and address format—that impact IMS peering. We
describe a proposal for a signaling routing process for
IMS peering, summarize our conclusions, and outline
key areas for further investigation.
Background
Today, when placing a Voice over IP call to reach
a destination endpoint served by a different VoIP
operator, most likely, the call is routed through the
PSTN. In some cases, even calls between two VoIP
subscribers served by the same SP are hairpinned over
the PSTN. The next section examines why it is so.
Why Are IMS-to-IMS Calls Routed Through the
PSTN Today?
One of the key issues that impede direct peering
among IMS networks is address resolution in support
of routing of SIP signaling messages, particularly dur-
ing session/call establishment or setup. In the PSTN
network, call routing is based on global addressing
using ITU-T E.164 [13] numbers (e.g., NPA-NXX-
XXXX in North America) to uniquely identify the
users, and on point codes to identify switching points.
In addition, the entire process is supported by com-
mon databases that are shared among carriers, such
as the local exchange routing guide (LERG), and by
pre-defined routing tables that associate switches with
telephone numbers.
Call routing in IMS, however, is completely
different from that in the PSTN. First, the current
IMS systems have not deployed a routing capability
that is fully equivalent to that of the existing PSTN.
Second, routing in IMS is based on a different entity:
SIP uniform resource identifiers (URI) [23]. SIP URIs
are used to identify IMS users and resources (e.g.,
servers and databases) and have a format similar to
an email address with a user name and a domain name
(e.g., sip:bob.smith@domain.com). The domain por-
tion identifies the host responsible for handling the
request for the user. For instance, the domain portion
may identify the IMS operator serving the particular
user. Hence, during call processing, SIP URIs need to
be resolved using domain name system (DNS) proce-
dures, described in [5], in order to determine the
IP address and port number of the corresponding
domain name server for the domain portion of the
SIP URI.
In the particular case where an E.164 telephone
number is used to establish a call, IMS invokes tele-
phone number mapping (ENUM) [7], an application
of the DNS, to perform the translation of the E.164
number into a SIP URI. The ENUM protocol uses a
specific naming authority pointer (NAPTR) DNS
resource record, the E.164-to-URI resolution (E2U),
as defined in [19], to identify and map the E.164
number with associated communications services
and resources (e.g., call server, email). This mecha-
nism allows a user to reach a destination by dialing
a telephone number, regardless of the device (e.g.,
phone, PDA) the destination party might happen to
be using. In short, in IMS, ENUM/DNS provides an
essential location function—equivalent to the LERG
in PSTN—for reaching a user identified with an
E.164 number.
This location function in IMS is at the heart of
the problem that forces routing through the PSTN for
IMS-to-IMS calls. Currently, there are several pro-
posals for ENUM/DNS implementation in support of
address resolution in IMS networks. However, there is
DOI: 10.1002/bltj Bell Labs Technical Journal 35
no agreement in the industry on a definitive solution.
These proposals are as follows:
• Global (public) ENUM is dedicated to making
ENUM data publicly accessible through the
E164.arpa domain at the public DNS root.
• Private ENUM is owned and controlled by a single
SP, which determines whether it wants to share
any information with another SP.
• Infrastructure ENUM, also known as carrier ENUM,
allows a group of carriers to share routing data
among themselves and to look-up the destina-
tion addresses of one another’s customers.
Note that both the private and the infrastructure
ENUM solutions are outside the scope of global ENUM
in that they do not use the E164.arpa domain.
However, they do share the same technological basis
and conventions as global ENUM.
Meanwhile, current implementations of IMS
networks by early adopters leverage private ENUM
solutions for the most part. That is, the private
ENUM database is mainly populated with NAPTR
records about the SP’s own subscribers. Hence, for
voice applications, if the called party (CdP) belongs to
a different IMS SP domain for which there is no
associated NAPTR record in the DNS server of the
originating network, the SIP URI address resolution
process results in an ENUM failure indicating that the
IMS domain does not know how to locate and route
the call to its destination. Today, when such a situa-
tion occurs, by default, the IMS network simply
routes the call to the PSTN. This default routing ends
up creating a PSTN bridge in between two IMS
islands, particularly when the destination party is an
IP endpoint.
The technical challenges associated with IMS sig-
naling peering are explored in more detail in subse-
quent sections. For now, suffice it to say that the PSTN
bridging model is not financially sustainable over the
long term, and it is not a technically viable option for
non-VoIP-only applications. The next section provides
an assessment of the impacts of PSTN bridging.
Impacts of PSTN Bridging
PSTN bridging in support of next-generation
applications will have serious financial implications
for IMS carriers in terms of both lost revenue oppor-
tunities and the opportunity to reduce operational
36 Bell Labs Technical Journal DOI: 10.1002/bltj
expenditures (OPEX) by retiring the PSTN more
quickly.
First, many IP and multimedia services (e.g., active
phone book, video telephony) requiring end-to-end
IP connectivity will not work over the PSTN. As a
result, an SP might be able to offer a particular serv-
ice to its own subscriber base; however, it will not be
able to guarantee that the service will work if the
other endpoint belongs to a different SP to which it is
only connected via the PSTN. Hence, there is a poten-
tial for lost revenue for the SPs. For instance, a VoIP
call initiated with a non-E.164 address (e.g., SIP URI)
to another IP endpoint will not work over the PSTN.
Support for such a service will require the initial SIP
INVITE message containing the destination SIP URI
to be encapsulated in ISDN user part (ISUP) and car-
ried over to the destination IMS domain via the SS7
network. SIP message encapsulation in ISUP messages
is not supported today and would require further
development in the PSTN, which is unlikely to occur.
In general, applications requiring end-to-end IP
fall into these categories:
• Peer-to-peer applications initiated with non-E.164
identifiers (e.g., initiating a voice call with the email
address of the called party).
• Applications requiring SIP signaling.
• Client/server applications that require end-to-end
IP connectivity (e.g., multiparty gaming).
• Applications requiring broadband access and
higher bandwidth than the 64 Kbps narrowband
used in the PSTN (e.g., video telephony).
Second, keeping a call between two IP endpoints
in the IP domain will help SPs avoid unnecessary set-
tlements and reduce charges associated with PSTN in-
terconnections. Moreover, relying on the PSTN to
support calls among IP endpoints ends up deferring
the decision to retire the PSTN more quickly, and de-
lays the opportunity for SPs to start realizing OpEx
savings for managing one packet network.
Last, PSTN bridging results in quality of service
(QoS) degradation caused by the cascading effect of
bearer conversions at the edges of the network. That
is, the bearer signal needs to be converted per ITU-T
G.711 specifications, thus incurring additional pro-
cessing delays in the media gateways placed on both
the ingress and egress sides of the PSTN.
 IMS domain A IMS domain B

IMS IMS
Application
application application

DNS/ DNS/
ENUM L5 peering ENUM

Other Other Call/

core IMS P/I/S-CSCF P/I/S-CSCF core IMS session
elements elements control

RACF RACF

Managed IP Managed IP
PSTN/PLMN
MG core PEP PEP core PEP

PEP Media/
access
IMS peering Wireless
PEP scope access network
Wireline
access network

CSCF—Call session control function MG—Media gateway

DNS—Domain name system
ENUM—Electronic number mapping
IMS—IP Multimedia Subsystem
IP—Internet Protocol
L5—Layer 5
PEP—Policy enforcement point
P/I/S-CSCF—Proxy/interrogating/serving CSCF
PLMN—Public land mobile network
PSTN—Public switched telephone network
RACF—Resource and admission control function

Figure 1.
IMS peering scope.

Need and Scope protocols such as Border Gateway Protocol (BGP)

As SPs continue to deploy IMS networks and
introduce next-generation (NG) applications to enh-
ance the end user experience, the need for peering
among IMS networks and across SP boundaries will
become critical.
As shown in Figure 1, IMS peering will occur
at different layers including network, policy, sig-
naling, and security. Layer 3 peering is well under-
stood—IP networks are interconnected today and
are well defined to support layer 3 peering. Much
work has been done in the RACF area, which de-
fines a framework for policy peering in support of
QoS [15].
However, peering at the session/signaling layer
(or layer 5) is not yet standardized. IETF SPEERMINT
recently defined a peering architecture [21] between
two SIP SPs, as depicted in Figure 2. The architec-
ture identifies the following logical functions:

DOI: 10.1002/bltj Bell Labs Technical Journal 37


LF
LF LF
Originating PF PF
SP‘s
network SF SF
MF MF
IETF—Internet Engineering Task Force
LF—Location function
MF—Media function
PF—Policy function
SF—Signaling function
SP—Service provider
SPEERMINT—Session Peering for Multimedia Interworking
Figure 2.
IETF SPEERMINT reference architecture.
1. Location function (LF) provides the routing data for
the purpose of the discovery of the signaling and
policy functions, and reaching the end user. The
LF, in fact, uses the ENUM/DNS infrastructure to
support the peering process.
2. Policy function (PF) provides a framework for
authentication and the exchange of policy param-
eters to be used by the signaling function.
3. Signaling function (SF) handles the routing of SIP
messages and assists in the discovery of param-
eters to be used by the media function.
4. Media function (MF) performs media-related func-
tions including media transcoding between two
SIP-based SPs’ networks.
The scope of our work, in what follows, is lim-
ited to the LF and SF, as described above.
IMS-to-IMS Signaling Peering for a Basic
Voice Call
In general, the inter-carrier signaling routing
process in IMS can be divided into the following
major phases:
1. Initialization and address analysis and resolution,
2. Determination of a peering point in the orig-
inating network,
3. Discovery of a peering point in the terminating
network, and
4. Routing in the terminating domain.
38 Bell Labs Technical Journal DOI: 10.1002/bltj
The next section discusses in detail the steps
associated with these phases.
Signaling Steps
In this example, each carrier implements a pri-
Receiving vate ENUM/DNS solution in its network, and domain
SP‘s
network A and domain B are the home networks for user
agent A (UAa) and user agent B (UAb), respectively.
For simplicity, the registration and authentication
steps, which would involve the use of an authentica-
tion, authorization, and accounting (AAA) server, and
the home subscriber server (HSS) are not shown. We
further assume that each domain contains only one
HSS server, and therefore the subscriber location
function (SLF) is not required. We also combine the
three call session control functions—interrogating
CSCF (I-CSCF), serving CSCF (S-CSCF), and proxy
CSCF (P-CSCF)—into a session manager (SM). Further-
more, we do not represent any element at the appli-
cation layer (e.g., a telephony application server or
TAS) that might be invoked during the call setup. Last,
we do not show the breakout gateway control func-
tion (BGCF) and media gateway control function
(MGCF) components, which would be invoked if the
call were destined for the PSTN/PLMN.
The signaling routing steps for a voice call between
UAa and UAb, shown in Figure 3, are as follows:
1. UAa initiates a SIP INVITE with UAb’s telephone
number, as the called party. The CdP number is
mapped into the request URI of the SIP INVITE.
2. Upon receiving the SIP INVITE, SMa queries the
ENUM server on the CdP: UAb.
3. Two cases might occur:
a. If the ENUM server does not contain a NAPTR
record for the CdP, and the carrier-of-record
associated with the CdP cannot be found or
reached via SIP peering, then the call is routed,
by default, to the PSTN. This case is not shown
on Figure 3.
b. Otherwise, the ENUM server returns a NAPTR
record to SMa with the domain name asso-
ciated with Uab.
4. SMa requests support from a local policy infra-
structure (Pa) to determine the peering point in
domain A (PPa) where it should forward the SIP
INVITE. PPa is an IBCF, which provides, among
 E D D E

IMS IMS
domain A 3 7 10 domain B
2 6 9 12 13

1 8 11 14 15
Peering IP
UAa SMa PPa network PPb SMb UAb

4
5

Pa Pb

D—DNS server IMS—IP Multimedia Subsystem PP—Peering point

DNS—Domain name system IP—Internet Protocol SM—Session manager
E—ENUM server P—Policy UA—User agent
ENUM—Electronic number mapping

Figure 3.
Signaling routing steps.

other things, firewall functions for signaling,
policing of signaling, and topology hiding.
5. Pa applies its local policy rules to determine the
appropriate peering point to handle the call, and
then forwards the SIP INVITE to SMa with the
URI associated with PPa.
6. SMa queries the DNS server in domain A to
retrieve the IP address for PPa.
7. The DNS server in domain A returns the PPa’s IP
address to SMa.
8. SMa sends the SIP INVITE to PPa with the domain
name serving UAb.
9. PPa queries the DNS in domain A to resolve the
address of a peering point in domain B (PPb). At
this stage, resolving the address of UAb results in
finding the IP address, port number, and transport
protocol for PPb.
10. DNS server returns the IP address of PPb to PPa.
11. PPa , as a gateway to external networks, may
encrypt part of the SIP message to perform the
topology hiding interface gateway (THIG)
function and forward the SIP INVITE to PPb.
12. PPb, upon determining that the domain associated
with the request URI is domain B, needs to forward
the SIP INVITE to SMb. The following steps, not
shown on the diagram, might occur in order to
locate SMb. If the SIP INVITE message does not
contain a route header field that points directly to
SMb, PPb sends a location-info-request (LIR) over
the Cx interface to the HSS to locate the appropriate
SM. HSS replies with a location-info-answer (LIA)
command that indicates the SIP URI of the server,
in this case SMb, that servesUAb.
13. PPb queries the DNS server in domain B to
obtain the IP address for SMb.
14. PPb forwards the SIP INVITE request to SMb.
15. SMb may invoke a TAS to apply further call logic
and forwards the SIP INVITE request to UAb.
16. UAb accepts the call and replies with a 200 OK
message to UAa, also not shown.
Issues Related to the Signaling Routing Steps
In this section, we analyze the signaling routing
steps discussed above to identify the salient rout-
ing issues that might occur in IMS network implemen-
tations. We group these issues under three categories
and discuss them separately.
CdP address resolution. As indicated in step 2, the
CdP address resolution is performed using the ENUM
service offered on the DNS server. In the example we

DOI: 10.1002/bltj Bell Labs Technical Journal 39

presented, the SP uses a private ENUM infrastructure,
which might not contain a NAPTR record for the CdP.
This might happen if a different SP serves the CdP. In
this case, the decision to route to the PSTN upon an
ENUM failure response, as described in step 3a, cre-
ates a routing dilemma because the CdP could be an
IP endpoint in domain B, and not a PSTN user. The
routing decision is based on not having the capability
to map the CdP telephone number with a SIP URI in
domain A, but does not take into consideration the
fundamental question as to whether the CdP is an IP
or a PSTN endpoint. In the latter case, it is appropri-
ate to route to the PSTN. In the former case, how-
ever, the call should simply be maintained in the IP
domain.
Finally, we believe that private ENUM implemen-
tation will not satisfy the long term need to remain
in the IP domain for an inter-domain call served by
different SPs. A long term solution should be based
on a common directory of telephone numbers and
associated domain names that are restricted to the SPs’
use and not accessible by public Internet users. Such
a common directory can cover many SPs across a
geographic area (e.g., regions in country) and be
administered by a trusted third party on behalf of the
SPs. This solution is conceptually similar to existing
administrative domains and database infrastructures
available in the PSTN, such as the telephone number-
ing plan or LERG.
Determining peering point in originating domain. In
step 4, we discussed another important aspect of the
signaling routing process: selection of a peering point
in the originating IMS domain. The originating IMS
network will need to make intelligent decisions in the
selection of its own signaling peering point in support
of call setup, as it will likely have multiple signaling
peering points to interconnect with other networks.
This decision is dynamic in nature and varies with the
target destination network of the CdP. SPs may employ
caching methods to minimize call setup delays of sub-
sequent calls in the selection of a peering point.
However, several other conditions in the originating
IMS network might influence such a selection as well.
For instance, the choice of a peering point can be
made based on quality of service policies (e.g., call
setup delay) defined to meet peering and user service
40 Bell Labs Technical Journal DOI: 10.1002/bltj
level agreements (SLA). Engineering factors such as
call rate, and current utilization of the proxy server
performing the peering function can lead to a distri-
bution of the calls among the available peering points
in support of load balancing requirements. Last, this is
an area that requires further investigation and would
most likely require support from a policy infrastructure.
We will discuss further aspects of this selection process
later in the paper.
Discovering peering point in terminating domain.
Step 10 discusses a DNS-based mechanism for the peer-
ing point in the originating network, which allows the
discovery of a peering point in the terminating net-
work. The IETF has addressed in detail the discovery
process of a proxy server (i.e., the peering point in our
context) in a different domain in RFC 3263 [22]. In
essence, the peering point in the originating network
makes use of DNS procedures, using both service
record (SRV) [11] and NAPTR records, to determine
the IP address, port, and transport protocol (e.g.,
Transport Control Protocol (TCP), User Datagram
Protocol (UDP), Stream Control Transmission Protocol
(SCTP), Transport Layer Security (TLS)), for the peer-
ing point in the terminating network. Additionally, RFC
3263 describes the procedures to allow the peering
point in the terminating network to discover a backup
peering point in the originating network, in case the
latter fails in the middle of the call setup transaction.
In short, the originating network will find all required
information to establish a call on IP to the terminating
network, including the border elements of the termi-
nating network.
The premise of RFC 3263, however, is based on a
global address resolution scheme that is accessible
through the E164.arpa domain at the public DNS root.
That is, SPs will have to publish SIP URIs of their peer-
ing points in the public DNS so that they know where
to signal one another. While such architecture works
reasonably well today for handling email services over
the Internet, its implementation in SP networks will
end up exposing their critical signaling resources to
Internet users. Thus, we believe that SPs deploying
IMS networks will be reluctant to embrace this solu-
tion until they can be assured that great concerns
about security risks or attacks on key signaling assets
are fully addressed.
 Meanwhile, a way forward is for SPs to create fed-
erations and use infrastructure ENUM/DNS for peering
point discovery within a federation. A federation is a
group of SPs that agree to accept calls from one another
via SIP, according to a set of administrative rules and
contractual financial terms established for such calls. In
the next section, we analyze other networking condi-
tions that impact the peering process as well.
Other Factors Influencing Signaling Peering
In addition to the issues identified in the signaling
steps, there are other important factors that will
influence the signaling peering process. In general,
these factors are related to the nature of the peering
infrastructure between the originating and terminat-
ing domain, as well as the handling of the CdP address
format and translation at the peering points.
Inter-Domain IP Infrastructure for Signaling
The inter-domain IP infrastructure between the
IMS originated and terminated networks can be one
of the following cases:
1. The public Internet.
2. Direct connections over leased lines, IP-virtual
private network (VPN) or tunneling over the
public IP network, among the SPs’ peering points
to create a fully meshed interconnect signaling
network.
3. A managed IP network commonly owned by the
SPs for the purpose of transferring IMS signaling-
related traffic among the different SP networks.
This case is similar to the proposed GPRS roaming
exchange (GRX) [9] of the GSM Association for
PLMN network interconnections.
4. A third-party-managed IP network similar to an
existing VoIP clearinghouse, an SP that offers
termination, financial services, and enhanced
applications to other SPs (e.g., Internet service
provider (ISP), VoIP) but serving the IMS SPs
signaling interconnection needs.
The inter-domain IP infrastructure need not be
an IMS network, but should ensure that key require-
ments—such as QoS, reliability, security, and address
resolution—are met. Issues related to IPv4-to-IPv6
interwork- ing are outside the scope of this document.
In what follows, we evaluate each inter-domain archi-
tecture alternative and its impacts on the signaling
Public
ENUM/
DNS
Domain A Internet Domain B
Domain Z
DNS—Domain name system
ENUM—Electronic number mapping
Figure 4.
Peering via public Internet.
peering process between the originating and termi-
nating IMS domains. We evaluate these alternatives
from the points of view of address resolution and
discovery of the peering point in the terminating
network.
The public Internet. This scenario, as shown
in Figure 4, leverages an open interconnection
architecture where the SPs’ peering points’ addresses
are public IP addresses and are directly accessible by
Internet users. This also implies that inter-carrier IMS
signaling messages are routed over the public Internet
without any guarantee that the signaling require-
ments (e.g., delay, priority of traffic) will be met. This
scenario has some key advantages. It potentially offers
a more open solution to the peering issue and enables
ad-hoc peering among SPs who do not have an
explicit peering agreement.
However, this scenario requires support from a
global ENUM/DNS system with global mapping of
E.164 numbers to DNS NAPTRs containing the SIP
URIs of all the SP peering points. For the reasons dis-
cussed earlier and related to universal connectivity
through global DNS, we do not believe this scenario
will address the SPs’ security concerns, and hence it is
not recommended.
Fully meshed interconnect network. This scenario
provides direct links among the SPs’ signaling peering
points and results in an n2 problem, where n is the
DOI: 10.1002/bltj Bell Labs Technical Journal 41

Domain A Fully meshed Domain B
Domain Z
Figure 5.
Peering via fully meshed network.
number of peering points, as illustrated in Figure 5.
SPs may use public IP addresses for their peering
points; however such addresses are not accessible
by public Internet users. The supporting DNS system
resolves the terminating peering point address into an IP
address that is routed over a particular link. In general,
this solution may prove not to be scalable for a large
number of peering points. However, SPs might decide to
selectively implement it to support high volume traffic
in between large communities of interests.
Common managed IP network. In this scenario,
depicted in Figure 6, the common managed IP net-
work is a private network. It may use public IP
addresses to route SIP requests to the SPs’ peering
points; however, these IP addresses are not accessible
by public Internet users.
In addition, this scenario requires an infrastruc-
ture ENUM/DNS system that is used only to resolve
SIP URIs associated with SP peering points, which are
attached to the common managed IP network. In
order to peer with a public domain (i.e., one not
attached to the managed IP network), the SP would
use a public Internet DNS for address resolution.
Hence, the public Internet DNS system is used to resolve
the domain names of all destinations not served
by the common managed IP network.
Finally, for traffic among the SPs served by the com-
mon managed IP network, the discovery of the ter-
minating peering point always results in finding the IP
address of an access server in the common managed
IP network. Once a SIP URI request is sent to the
common managed IP network, the infrastructure
ENUM/DNS server resolves the associated domain
42 Bell Labs Technical Journal DOI: 10.1002/bltj
Public Domain X
ENUM/
DNS
Carrier
ENUM/
DNS
Managed IP
Domain A Domain B
network
Domain Z
DNS—Domain name system
ENUM—Electronic number mapping
IP—Internet Protocol
Figure 6.
Peering via managed IP network.
name into the IP address of the terminating peering
point.
Clearinghouse model. This scenario, also shown in
Figure 6, is functionally the same as the one depicted
for the common managed IP network, except that a
clearinghouse provides the administration of the
inter-domain IP infrastructure. A variant of this case
is that the clearinghouse is only used as a trusted third
party registry administering the infrastructure ENUM/
DNS hierarchy and providing SPs with the routing
information needed for address resolution.
In summary, the nature of the inter-domain IP
infrastructure impacts the address resolution process
for the discovery of the terminating peering point. It
further determines what network knowledge is requi-
red to reach the terminating domain. For instance, in
the first scenario, a global directory ENUM/DNS is
required, whereas in the second case, static routing
tables might be sufficient to reach the terminating
network. Hence, the call processing algorithm for SIP
peering should take the inter-domain infrastructure
into consideration.
Transit network/federation. In the absence of a
global directory ENUM/DNS, SPs will likely group
 Domain X

3 Fe
n de
io ra
at A –X–Z tio
der n
Fe 4

Domain A Federation 1 Domain B Federation 2 Domain Z

A–B–Z

Figure 7.
Peering via transit.

themselves into federations to satisfy their intercon-
nection needs. Figure 7 illustrates a multi-federation
arrangement among four SP networks. Moreover, it
shows that the relationship with a federation might
not be exclusive. An SP might belong to more than
one federation for various financial and technical rea-
sons. For instance, domain A belongs to federations
1 and 3. Furthermore, an SP which belongs to multi-
ple federations might offer to become a transit SP for
other SPs. In our example, domains B and X can be
such transits for domains A and Z. Likewise, domains
A and Z can be used as transits for traffic between do-
mains X and B. As a result, domain A can use either
domain X or domain B to reach domain Z. Therefore,
a key question a routing algorithm needs to address is
which federation to use to reach a target destination.
In addition, [16] and [12] discuss the need for fed-
erations to use fully qualified domain names as their
identifiers, and that members of a federation might
need to publish federation membership as domain
attributes. In other words, to route a call to its destina-
tion, the originating network might need to retrieve the
set of federations to which the terminating network
belongs. If there is a shared federation, which can be
determined through the domain policy dynamic
delegation discovery system (DDDS) application as spec-
ified in [17], it is used to support the call. Otherwise, the
originating network might route the call to a transit SP.
Thus, matching a common federation or selecting the
right transit network to use to reach a destination
becomes a critical part of the signaling peering routing
process and must be taken into consideration by the
routing algorithm during call processing.
Identification and Address Format
IMS, as for any type of network, provides mecha-
nisms to uniquely identify users so that calls can be
appropriately routed to them. IMS uses public user
identities (PbUI) and private user identities (PrUI) to
identify its users. PbUI are SIP URIs or TEL URIs [24]
and are used to route SIP signaling in IMS. As discussed
earlier, SIP URIs are in the form of sip:⬍user⬎@oper-
ator.com, where the user part can be an E.164 tele-
phone number. A TEL URI, however, is in the form of:
tel:⫹1-NPA-NXX-XXXX, to represent, for example, a
telephone number in the North America Numbering
Plan. The TEL URI is used when the domain of own-
ership of the phone number is unknown. SIP, how-
ever, requires that the URI under registration be a SIP
URI [3]. Hence, it is not possible to explicitly register a
TEL URI in SIP. However, PrUIs do not use SIP URI
or TEL URI formats. Instead, they use a network access
identifier (NAI) in the form of ⬍user⬎@operator.com.
They are exclusively used for subscription identifica-
tion and authentication purposes [3].
The rest of the paper focuses on analyzing the SIP
URI-based PbUI formats and their impacts on IMS
signaling peering.

DOI: 10.1002/bltj Bell Labs Technical Journal 43

 SIP URI formats for the PbUI. IMS users will use a
variety of devices (e.g., PDA, IP phone) to trigger NG
services and to initiate calls to other users. Likewise,
SPs may assign more than one PbUI to their customers
so they can be reached through a variety of means
(e.g., email, business phone). As a result, SIP URIs as-
sociated with PbUIs can take various forms, as de-
scribed in [6], including the following:
1. sip:⫹⬍E.164⬎@⬍service provider⬎;user ⫽ phone
2. sip:⬍user⬎@⬍service provider⬎
3. sip:⬍user⬎@⬍domain name⬎
4. sip:⬍ip address⬎
Impacts on address resolution for SIP peering. The
format of the SIP URIs, as presented above, might in
some cases render impossible the resolution of the
destination address of the CdP. For instance,
⬍user⬎@⬍domain name⬎ (case 3) might be impos-
sible to resolve if used to initiate a call. First, assuming
the domain name can be resolved to an associated
SP domain, as discussed above, ⬍user⬎@⬍service
provider⬎ might not be unique in the SP domain.
Second, different users belonging to a domain name
might be served by different SPs. For example, johndoe
@alcatel-lucent.com might be served by a different SP
than janedoe@alcatel-lucent.com. Therefore, the res-
olution of a ⬍user⬎@⬍domain name⬎ SIP URI
should identify the specific SP serving each particular
user. That is, the ⬍domain name⬎ server might need
to be a redirect server pointing to the carrier-of-record
that serves the user. This can be an implementation
nightmare in that all domain names will be required
to support the redirect function. Last, considerations
should be given to the additional delay such a process
will introduce on key performance parameters such as
call setup time.
In summary, the format of the SIP URI used to
initiate a call will impact the signaling routing process
in the originating domain as well as in any transit net-
work that might be used to support the call. In addi-
tion, some formats might be impossible to resolve in
support of inter-carrier communications.
Proposed Signaling Peering Process
In order to define an appropriate peering and
routing approach for a given scenario, one needs to
consider and evaluate the end-to-end process. In light
44 Bell Labs Technical Journal DOI: 10.1002/bltj
of the routing steps and issues discussed above, we pro-
pose a high level signaling peering process, which
provides a comprehensive approach to signaling
peering and takes into account multiple constructs
(e.g., IP networks, federations, and transits) that might
exist between the originating and terminating domains.
Moreover, the proposed signaling peering process
addresses the need to perform address translation in
support of service portability as an essential step for
inter-carrier communications. A key assumption, in
this regard, is that “all call query,” a method by which
a number portability query is performed on all origi-
nating calls as described in [8], is used as the service
portability implementation option.
Signaling Process for IMS Peering
Figure 8 illustrates the signaling peering process
for a basic voice call initiated with an E.164 number,
which we describe as follows:
1. The calling party initiates the call with a dial
string, which the originating network converts
into a fully qualified E.164 number.
2. Map the CdP’s E.164 number into SIP headers
(e.g., request URI, ‘To ⫽ ’) and send the app-
ropriate INVITE request to the session manager
in the originating network.
3. Analyze the CdP address for service portability
(e.g., SP portability).
4. If the CdP is not ported, proceed with 6.
5. If the CdP is ported:
– Perform the portability database lookup to
retrieve the location routing number (LRN)
associated with the CdP. Note that this paper
does not specify an infrastructure for perfor-
ming a number portability (NP) database (DB)
query. Options range from reusing existing
NPDBs in the intelligent network (IN) to ret-
rieving a NAPTR record from an ENUM/DNS
query pointing to the LRN.
– Append the ‘npdi ⫽ yes’ field to the request
URI header in the subsequent SIP URI request
created with the LRN.
6. Perform address resolution of the CdP or LRN
through the ENUM/DNS infrastructure to de-
termine which destination network the CdP
belongs to. The output of this step results in a
 Identifier CdP ID mapping RFC 3261
Request URI

PbUl:SIP URI or CdP address

TEL URI analysis ENUM/DNS queries for NP or
query NPDB via IM-SSF

All call query Y Perform NP lookup and

Perform
Is CdP open to portability? NPDB? address translation

What‘s the domain name of CdP SP? N

Is CdP served by initiating domain?
obtain ENUM/DNS NAPTR Address resolution
Invoke policy peering function for
How to determine that the establishing the nature of peering
CdP belongs to the PSTN? network (e.g., federation, transit)
Y CdP in N
PSTN

Is RFC 3263 sufficient?

Invoke BGCF Peering scenario Determining/locating PP?
(originating/terminating)

Selection based
on NPA-NXX and Select MGCF/MGW Discover peering point ENUM/DNS with
local policy rules local policies

Obtain PSTN routing Resolve PP address SIP address translation

data (e.g., from LERG) Perform SIP/ISUP
conversion and mapping
Generate ISUP IAM
Translate CdP
Determine S-CSCF serving
Route to PSTN CdP and route to CdP

Terminating Y Route SIP invite to CdP

PSTN endpoint
domain in terminating domain

N
IP endpoint
Route to next domain

BGCF—Breakout gateway control function NAPTR—Naming authority pointer

CdP—Called party NP—Number portability
CSCF—Call session control function NPA—Numbering plan area
DNS—Domain name system NPDB—Number portability database
ENUM—Electronic number mapping PP—Peering point
IAM—Initial address message PSTN—Public switched telephone network
ID—Identifier RFC—Request for comments
IM—IP Multimedia S-CSCF—Serving CSCF
IP—Internet Protocol SSF—Service switching function
ISDN—Integrated services digital network SIP—Session Initiation Protocol
ISUP—ISDN user part SP—Service provider
LERG—Local exchange routing guide TEL—Telephone
MGCF—Media gateway control function URI—Uniform resource identifier
MGW—Media gateway

Figure 8.
Proposed signaling peering process.

DOI: 10.1002/bltj Bell Labs Technical Journal 45

 SIP URI that represents an address of record for
the CdP.
7. If the call is destined to the PSTN, invoke the
BGCF to determine which MGCF to provide
the ISDN user part and SIP interworking func-
tion, as defined in [4], and then route the call to
the PSTN.
8. Otherwise, determine whether a common fed-
eration exists between the originating and ter-
minating domains:
– If so, consult the policy peering infrastructure
and apply common federation rules to dis-
cover the peering point in the terminating
network.
– If not, determine a transit network to support
the call and apply corresponding federation
rules for the transit.
9. Determine the peering point in the originating
network according to the local policy infrastruc-
ture and procedures defined in RFC 3263 [22].
10. Perform the SIP header translation at the
peering point and according to the SIP URI
format used, if necessary.
11. Route the SIP INVITE to the next hop (e.g.,
proxy/access server in federation) towards the
destination
12. When the terminating domain is reached,
determine the serving CSCF for the CdP, locate
the CdP, and route the INVITE to the CdP.
13. Establish the session and transfer of media.
Proposal Benefits
The end-to-end signaling peering process
described above introduces new decision points and
routing steps during call setup for inter-carrier com-
munications. The benefits of such a process include:
1) support for number portability, 2) more efficient
routing among IP endpoints, and 3) avoidance of
unnecessary delays during call setup. The following
discusses these benefits.
Support for number portability. In many countries,
number portability (NP) is a regulatory requirement
that SPs must comply with. As presented in step 4
and step 5 in the section above, support for NP
requires SPs to perform user identification translation
for the CdP. The outcome of the translation process
46 Bell Labs Technical Journal DOI: 10.1002/bltj
helps determine which network to route a call to for
inter-carrier communications. Various options are im-
plemented for NP. For instance, in the United States,
SPs implement the “all call query” option for service
provider number portability (SPNP), which allows a
user to change the SP while keeping the same
telephone number. SPNP leaves the responsibility for
performing the NPDB query to the penultimate net-
work. This decision is somewhat straightforward
in the PSTN in that for a long distance (LD) call, the
carrier of record for LD services is the penultimate
network, and, hence, it performs the query. For a toll
local call, the local SP is the penultimate network and,
as such, does the query.
IMS, however, introduces new challenges in sup-
porting NP. First, as discussed above, the CdP identifi-
cation might not be an E.164 number. Obviously, in
such cases, existing E.164-based NP databases cannot
be leveraged. Therefore, translation between SIP URIs,
and IP addresses via DNS in support of NP, becomes a
critical function in determining the next domain/
network towards a destination.
Moreover, the decision as to which SP should per-
form the NPDB becomes more complex in IMS, if we
ought to follow the penultimate model discussed
above. How to determine which network is next to
the last before performing address translation of the
CdP? In today’s deployment of VoIP networks, these
demarcation lines are not clearly defined. As a case in
point, VoIP service offerings assume mobility of end-
points. For instance, one can be living in California
and may get assigned a phone number with a New
Jersey numbering plan area (NPA) (e.g., 732). This
proposal simplifies the decision process by recom-
mending that the originating network always perform
the appropriate translation of the CdP address on all
calls, once it determines that such an address is open
to portability.
Determining the nature of CdP endpoint. Another
important decision point during call processing,
summarized in step 7 and step 8 above, is for the
originating network to determine whether the CdP
is a PSTN or IP endpoint, so the call is handled appro-
priately. Otherwise, SPs will continue to use PSTN
bridging for IP-to-IP inter-carrier calls. At this point, it
is not clear whether the mechanism to identify the
nature of an endpoint (i.e., PSTN or IP) would exist
outside the ENUM framework. Hence, as discussed
earlier, we recommend that a common directory of
telephone numbers and associated domain names
(e.g., carrier ENUM) be in place to support that
decision point. Such an infrastructure should be
restricted to SP use and would be inaccessible to
public Internet users.
This proposal takes advantage of the recom-
mended common infrastructure to help determine
whether a call terminates in the PSTN or in another
IMS domain and to route it accordingly.
Avoiding additional call setup delay. A net benefit of
determining the nature of the CdP endpoint is to avoid
the additional call setup delay, as defined in ITU-T
E.127 [14], which might occur in the PSTN when
bridging two IMS islands. For instance, for calls in the
PSTN, E.127 recommends an average call setup delay
of no more than 3 seconds and 5 seconds, respectively,
for local and toll calls. The 95th percentiles are
6 seconds and 8 seconds, respectively.
Conclusions and Areas for Further Investigations
IMS network signaling peering is a very complex pro-
blem to tackle for the deployment of next-generation
IMS networks. Unlike the embedded base PSTN/PLMN,
where common databases and established routing prin-
ciples allow SPs to securely share call routing data and
identify one another’s signaling points, there are new
challenges facing the IMS SPs. First, SPs need to per-
form address resolution of users’ identifiers (e.g., SIP
URI) and other resources (e.g., call servers) at almost
every step during call setup. Second, the format of the
identifiers may vary depending on what service is being
initiated. Accordingly, the address resolution process
requires different mechanisms to identify the users and
their serving domains. Third, the nature of the infra-
structure between two SP networks impacts the peer-
ing process in that it influences the discovery of the
peering points for a given call. Last, SPs will create fed-
erations and transit networks for network intercon-
nect, as achieving universal connectivity is an
unrealistic goal. Hence, the selection of what federa-
tion/transit network to use to reach a destination be-
comes an integral part of the signaling peering decision
process.
This paper discusses these new challenges and
proposes a high-level signaling process that identifies
key peering decision points and provides a compre-
hensive approach to solving them. Such an approach
is necessary for accelerating the deployment of IMS
networks and reducing the reliance on PSTN/PLMN
network for inter-carrier communications among IP
endpoints.
Finally, it is clear that more detailed work is
needed to address some specific technical challenges
identified in this paper. However, in priority order,
the following areas are critical for further investiga-
tions. First, more work is needed to define the re-
quirements for a policy peering infrastructure in
support of intelligent selection of peering points in an
SP IMS network. This will invoke the PF in both the
originating and terminating IMS networks and apply
policy rules for the selection of the peering points.
Second, a new routing algorithm for the selection of
federation/transit in a multi-transit/federation sce-
nario is needed. This will invoke the LF and PF in
both originating and terminating networks.
Acknowledgments
The author would like to acknowledge several
colleagues for sharing their insights on various aspects
of this work. In particular, he is grateful to Deirdre
Doherty, Mohamed El-Sayed, Igor Faynberg, Paul
Gagen, Vijay Gurbani, Volker Hilt, Markus Hofmann,
Vanita Katkar, Eunyoung Kim, Lyle Kipp, Humberto
La Roche, Tom Morawski, Bob Moul, Morgan Stern
and Carlos Urrutia-Valdés.
*Trademarks
3GPP is a trademark of the European Telecommunica-
tions Standards Institute.
References
[1] 3rd Generation Partnership Project,
“Architectural Requirements,” 3GPP TS 23.221,
June 2004, ⬍http://www.3gpp.org/ftp/
Specs/html-info/23221.htm⬎.
[2] 3rd Generation Partnership Project, “IP
Multimedia Subsystem (IMS), Stage 2 (Release
7),” 3GPP TS 23.228, v7.2.0, Dec. 2005,
⬍http://www.3gpp.org/ftp/Specs/html-
info/23228.htm⬎.
[3] G. Camarillo and M. A. Garcia-Martin, The 3G
IP Multimedia Subsystem (IMS): Merging the
DOI: 10.1002/bltj Bell Labs Technical Journal 47
 Internet and the Cellular Worlds, 2nd ed., John
Wiley and Sons, Chichester, England, Hoboken,
NJ, 2006.
[4] G. Camarillo, A. B. Roach, J. Peterson, and
L. Ong, “Integrated Services Digital Network
(ISDN) User Part (ISUP) to Session Initiation
Protocol (SIP) Mapping,” IETF RFC 3398,
Dec. 2002, ⬍http://www.apps.ietf.org/rfc/
rfc3398.txt⬎.
[5] R. Daniel and M. Mealling, “Resolution of
Uniform Resource Identifiers Using the Domain
Name System,” IETF RFC 2168, June 1997,
⬍http://www.apps.ietf.org/rfc/rfc2168.txt⬎.
[6] European Telecommunications Standards
Institute, “Interconnect and Routing Issues
Related to Numbering Naming and Addressing
(NN&A) for Next Generation Networks (NGNs),”
DTR/TISPAN-04006-Tech, ETSI TR 184 006,
v0.0.6, Feb. 2006, ⬍http://www.etsi.org⬎.
[7] P. Faltstrom and M. Mealling, “The E.164 to
Uniform Resource Identifiers (URI) Dynamic
Delegation Discovery System (DDDS) Application
(ENUM),” IETF RFC 3761, Apr. 2004,
⬍http://www.apps.ietf.org/rfc/rfc3761.txt⬎.
[8] M. Foster, T. McGarry, and J. Yu, “Number
Portability in the Global Switched Telephone
Network (GSTN): An Overview,” IETF RFC
3482, Feb. 2003, ⬍http://www.apps.ietf.org/
rfc/rfc3482.txt⬎.
[9] GSM Association, “Inter-PLMN Backbone
Guidelines,” Doc. IR.34, Revision 3.7, Apr. 2006.
[10] GSM Association, “IMS Roaming and
Interworking Guidelines,” Doc. IR.65, Revision
3.5, Aug. 2006.
[11] A. Gulbrandsen, P. Vixie, and L. Esibov, “A DNS
RR for Specifying the Location of Services
(DNS SRV),” IETF RFC 2782, Feb. 2000,
⬍http://www.apps.ietf.org/rfc/rfc2782.txt⬎.
[12] M. Haberler, M. Hammer, and O. Lendl, “A
Federation Based VoIP Peering Architecture,”
IETF Internet Draft, Sept. 2006,
⬍http://www.ietf.org⬎.
[13] International Telecommunication Union,
Telecommunication Standardization Sector,
“The International Public Telecommunication
Numbering Plan,” ITU-T Rec. E.164, May 1997,
⬍http://www.itu.int⬎.
[14] International Telecommunication Union,
Telecommunication Standardization Sector,
“Network Grade of Service Parameters and
Target Values for Circuit-Switched Services in
the Evolving ISDN,” ITU-T Rec. E.721, May
1999, ⬍http://www.itu.int⬎.
48 Bell Labs Technical Journal DOI: 10.1002/bltj
[15] International Telecommunication Union,
Telecommunication Standardization Sector,
“Resource and Admission Control Functions in
Next Generation Networks,” ITU-T Rec. Y.2111,
Sept. 2006, ⬍http://www.itu.int⬎.
[16] O. Lendl, “Publishing SIP Peering Policy,”
IETF Internet Draft, Dec. 2005,
⬍http://www.ietf.org⬎.
[17] O. Lendl, “The Domain Policy DDDS
Application,” IETF Internet Draft, Feb. 2006,
⬍http://www.ietf.org⬎.
[18] R. Mahy, “A Minimalist Approach to Direct
Peering,” IETF Internet Draft, June 2006,
⬍http://www.ietf.org⬎.
[19] M. Mealling, “Dynamic Delegation Discovery
System (DDDS) Part Three: The Domain
Name System (DNS) Database,” IETF RFC 3403,
Oct. 2002, ⬍http://www.apps.ietf.org/
rfc/rfc3403.txt⬎.
[20] J.-F. Mule, “SPEERMINT Requirements for SIP-
Based VoIP Interconnection,” IETF Internet
Draft, June 2006, ⬍http://www.ietf.org⬎.
[21] R. Penno (ed.), “SPEERMINT Peering
Architecture,” IETF Internet Draft, Aug. 2006,
⬍http://www.ietf.org⬎.
[22] J. Rosenberg and H. Schulzrinne, “Session
Initiation Protocol (SIP): Locating SIP Servers,”
IETF RFC 3263, June 2002, ⬍http://www.apps.
ietf.org/rfc/rfc3263.txt⬎.
[23] J. Rosenberg, H. Schulzrinne, G. Camarillo,
A. Johnston, J. Peterson, R. Sparks, M. Handley,
and E. Schooler, “SIP: Session Initiation
Protocol,” IETF RFC 3261, June 2002,
⬍http://www.apps.ietf.org/rfc/rfc3261.txt⬎.
[24] H. Schulzrinne, “The tel URI for Telephone
Numbers,” IETF RFC 3966, Dec. 2004,
⬍http://www.apps.ietf.org/rfc/rfc3966.txt⬎.
(Manuscript approved August 2007)
JEAN-PHILIPPE JOSEPH is a member of technical staff in
the Advanced Network Planning and
Modeling group at Alcatel-Lucent in Murray
Hill, New Jersey. He holds a B.S. in
electronics engineering from La Faculté des
Sciences de l’Université d’Etat d’Haïti in
Port-au-Prince, and an M.S. degree in electrical
engineering from Polytechnic University of New York in
New York City. Mr. Joseph’s current research interests
include IMS-based architectures and solutions for
network evolution and service integration, IMS
signaling peering, network modeling, and
optimization. ◆