S. Lind
Internet Draft AT&T
Document: draft-lind-enum-callflows-02.txt November 2001
Category: Informational
ENUM Call Flows for VoIP Interworking
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 made obsolete 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.
1. Abstract
This document provides illustrations of the use of ENUM [2]
functionality and identifies issues associated with such use. To
accomplish this objective, the document presents service-level call
flows for Voice over IP communication where interworking between the
PSTN and IP-based networks are necessary to complete a call. Details
are presented for simple calls made on a ôdirect dialö basis. For
more complicated calls, those requiring number portability or
interactive call processing (e.g., freephone), the issues are
described with the intent of working through those issues in
subsequent drafts. The document does not propose that the examples
represent the only or best approach for interworking between the
PSTN and IP-based networks.
2. Conventions used in this document
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 RFC-2119 [3].
Lind Information - May 2002 1
ENUM Call Flows for VoIP Interworking November 2001
2.1 Definitions
ITSP - Internet Telephony Service Provider. An entity that has been
certified by the regulatory authority, where required, within a
given country to provide (originate and complete) telephony service
using IP technology.
3. Scope of Work
It is envisaged that this document could be used by the ITU to cull
the various service requirements out of the examples presented and
to use those requirements as the main part of a new draft
Recommendation (preliminarily called ôE.callflowsö). An example of
such a requirement would be that the ENUM-enabled client must take
the local dialing plan into account.
After the requirements are identified, any necessary protocol
enhancements need to be identified. Some of this work may already be
in progress within the IETF and close co-operation between the ITU
and the IETF will speed this process of discovering existing work
and initiating new work. Some areas that need exploration include
the ability to transport number portability information within the
SIP messages, the ability for the TRIP protocol to address global
service codes and network-specific numbers, and the need to
interface with IN databases to ensure that interworking is fully
functional.
It is also expected that the illustrations and examples may be
useful as appendices in the final Recommendation.
4. Background
ENUM provides the capability to translate an E.164 Telephone Number
into a set of URIs using the Domain Name System (DNS). This
capability has different uses depending on the services being used
and, in the case of voice services, the technology available at the
source and destination of the communication.
In a pure IP environment, ENUM will allow end users to be identified
by a commonly used name (i.e., their telephone number) for a variety
of applications. The potential for this capability simplifies the
requirements spelled out in ITU-T Recommendation E.123, ôNotation
for National and International Telephone Numbers, E-Mail Addresses
and Web Addressesö. It also implies that end users can change IP
service providers without having to change their destination
identification. For example, an end user can change their underlying
e-mail address from ôjohn@abc.comö to ôjohn@xyz.comö but, with ENUM
set up to handle e-mail using the ôE2Uö records specified in RFC
2916, still be reached by having ENUM-enabled mail clients send mail
addressed to their ôtelephone numberö (e.g., mailto:+1-973-236-
6787).
Lind Information - May 2002 2
ENUM Call Flows for VoIP Interworking November 2001
For voice services, ENUM will allow the easy end user identification
described above as well as interworking between terminals on the
PSTN and on the IP-based network. It may also allow for the
implementation of more advanced services, such as ôfind-me.ö For
voice communication starting on an IP-based network, ENUM can be
used on each call to determine the preferred type of destination
based on the priority of the network termination available. For
voice communication starting on the PSTN, ENUM may be used where at
least one of the destinations of the call exists on an IP-based
network.
+----------------+-----------------+----------------+--------------+
|\ Termination | IP-based | Both | PSTN Only |
| -------------- | Network Only | | |
| Origination \| | | |
+----------------+-----------------+----------------+--------------+
|IP-based |ENUM used for ad-|ENUM used to de-|ENUM used to |
| Network |dress translation|termine destina-|determine ad- |
| |and, to some ex- |tion (based on |dress transla-|
| |tent, service |service priori- |tion |
| |priority |ty) and address | |
| | |translation | |
+----------------+-----------------+----------------+--------------+
|PSTN |ENUM used for ad-|ENUM may be used|ENUM may not |
| |dress translation| |be used |
+----------------+-----------------+----------------+--------------+
Table 1 - Use of ENUM resources
5. Simple Voice Service Interworking
5.1 Call from the PSTN to a Terminal on an IP-based Network
This scenario is illustrated in figure 1. A customer on the PSTN
wishes to reach another customer whose terminal (ôphoneö) is
connected to an IP-based network. In the illustration, the
destination terminal is a SIP client, but other client protocols may
be equally applicable. The various steps are denoted in parentheses
within the figure and explained below. No aspects of number
portability are included in the scenario.
Lind Information - May 2002 3
ENUM Call Flows for VoIP Interworking November 2001
+--------+ +--------+ (2) +--------+
| | | |---------->| | (3)
| POTS |---------->| PSTN | | Gateway|
| Phone | (1) | |<.........>| | (5)
+--------+ +--------+ +--------+
^ | ^
: | :
(7) : | :
: | :
+--------+ +--------+ +-:-+-:--+
| | | |<............: | : |
| SIP |<----------| SIP | |IP-based|
| Client | (8) | Server |<----------+ Network|
+--------+ +--------+ +-----:--+
:
v
+--------+
---> Voice Path | | (4)
...> Signaling Path | DNS |
| | (6)
+--------+
Figure 1
Call From PSTN to IP-based Network
Step 1 - The originating customer dials an E.164 number. The actual
digits dialed depend on the dialing plan in effect at the point of
origination. The customer may dial a local number (or intra-NPA
within the US), an intercity number (or inter-NPA within the US), or
international number. Any dialing prefixes required by the dialing
plan must be entered.
As an example, John Smith, whose phone number in the US is 301-555-
1234, wants to call Jenny Jones. The number that John Smith has for
Jenny, also in the US, is 301-236-6787. John dials ô236-6787ö [the
hyphens are provided for readability and are not dialed]. It is
worth noting that any dialed prefixes are usually dropped at the
first switching point within the PSTN.
As a second example, John Smith wants to call Franz Himmel in
Switzerland. FranzÆs local number is 022-730-5887. John Smith would
dial ô011-41-22-730-5887ö (011 being the dialing prefix for
international calls placed from the United States and 41 being the
country code for Switzerland).
Step 2 - The PSTN Service Provider forwards the call to the
appropriate Gateway. Selection of the appropriate Gateway may depend
on a number of different factors, including regulatory factors in
effect at the point of call origination. The physical location of
the Gateway in relation to the point of origination may also depend
on several factors including the relationships between the PSTN
Service Provider and the Internet Telephony Service Provider (ITSP)
at the point of termination.
Lind Information - May 2002 4
ENUM Call Flows for VoIP Interworking November 2001
Within the first example, John SmithÆs local service provider
determines that the call is local, but not served by this provider.
The originating provider forwards it to JennyÆs ITSP as the
terminating local service provider.
In the second example, the international carrier is handed the call.
The call could be routed to an international switching center where
the call is handed to another international carrier (where a gateway
might be selected) or, if it can be determined that the destination
is on an IP-based network, the gateway can be selected earlier in
the call flow.
Step 3 - The Gateway looks up the domain name in DNS. The Gateway at
which the call enters the IP-based network must contain any ENUM
functionality to transform the dialed digits to a fully qualified
domain name (FQDN). The gateway must supply any missing digits in
order to obtain a fully qualified E.164 number as part of the
transformation.
In the first example, the gateway transforms the dialed number into
a FQDN of ô7.8.7.6.6.3.2.1.0.3.1.e164.arpaö. During the
transformation, the country and area codes for the destination are
added to the number by the gateway. In the second example, the
gateway transforms the dialed number into a FQDN of
ô7.8.8.5.0.3.7.2.2.1.4.e164.arpaö. In this second example, the
country code is already present in the dialed digit stream.
Step 4 - The DNS returns any service records associated with the
URL.
In the first example, the DNS returns among the records one
containing the URI ôsip:jennyjones@sipservice.fooö. In the second
example, the DNS returns a record containing the URI
ôsip:franz.himmel@sipserver.bar.chö.
Step 5 - The Gateway looks up the address (A) record for the
specified host (e.g., ôsipservice.fooö) in DNS.
Step 6 - DNS returns the IP address of the SIP server for the
specified host.
Step 7 - The call is routed through the IP-based network to the
designated IP address.
Step 8 - The SIP Server routes the call to the user agent client of
the specified user (e.g., ôjennyjonesö). When the destination party
answers, answer supervision must be returned to the originating
local switch.
A protocol diagram of this call flow is contained in Appendix 1.
Lind Information - May 2002 5
ENUM Call Flows for VoIP Interworking November 2001
5.2 Options In Identifying the Gateway
The most significant problem in the above scenario is the
determination of when the call must be routed to the IP-based
network via the gateway. The easiest way to solve the problem would
be to use different E.164 numbers for terminals on the IP-based
network. However, this solution may not be feasible in certain
regulatory environments where the available numbering resources are
scarce.
Another way to solve the problem is to route all calls to a gateway
to transport the calls over an IP-based network, completing those
calls to IP terminals where possible and allowing the remaining
calls to egress back to the PSTN close to their destination. In the
latter case, it may be useful, but not mandatory, to have ôtel:ö
records to facilitate the routing to the destination gateway.
There may be other solutions that lie between the previously
described methods. Those possible solutions are outside the scope of
this paper, but development work would be needed to implement such
capabilities.
5.3 Call from a Terminal on an IP-based Network to a phone on the PSTN
This scenario is illustrated in figure 2. A customer on an IP-based
network wishes to reach another customer whose phone is connected to
the PSTN. In the illustration, the originating terminal is a SIP
client, but other client protocols may be equally applicable. No
aspects of number portability are included in this scenario. The
various steps are denoted in parentheses within the figure and
explained below.
+--------+ +--------+ (5) +--------+ +--------+
| |(1,2,4) | |<........ ........>| LS | (6)
| SIP |------->| SIP |--------+IP-based| : +--------+
| Client |<......>| Server |<........ Network| : +--------+
+--------+ +--------+ +--:--+--+ :....>| DNS | (3)
: | +--------+
(7) : |
v v
+--------+ +--------+ +--------+
| | | |<......>| |
| POTS |<-------| PSTN | | Gateway| (8)
| Phone | | |<-------| |
+--------+ +--------+ +--------+ ---> Voice Path
...> Signaling Path
Figure 2
Call from IP-based Network to PSTN
Step 1 - The originating customer dials an E.164 number. The actual
digits dialed depend on the dialing plan in effect at the point of
Lind Information - May 2002 6
ENUM Call Flows for VoIP Interworking November 2001
origination. The customer may dial a local number (or intra-NPA
within the US), an intercity number (or inter-NPA within the US), or
international number. Any dialing prefixes required by the dialing
plan must be entered.
As an example, Jenny Jones, who has a SIP client and whose ôphone
numberö (the same number as assigned by her TSP) in the US is 301-
236-6787, wants to call John Smith. The number that Jenny has for
John, also in the US is 301-555-1234. Jenny dials ô555-1234ö.
Step 2 - The SIP Client looks up the name in DNS. The SIP Client
must contain any ENUM functionality to transform the dialed digits
to an Fully Qualified Domain Name (FQDN). The SIP Client must supply
any missing digits in order to obtain a fully qualified E.164 number
as part of the transformation.
In the example, the SIP Client transforms the dialed number into a
FQDN of ô4.3.2.1.5.5.5.1.0.3.1.e164.arpaö. During the
transformation, the country and area codes for the destination are
added to the number by the client.
Step 3 - The DNS returns any NAPTR service records associated with
the FQDN.
In the example, the DNS returns, most likely, only one record
containing the URI ôtel:+13015551234ö.
If no ENUM record exists for the URL, the call should be attempted
for termination on the PSTN using the dialed digits as the target
for further steps in the call flow.
Step 4 - The SIP Client initiates a SIP INVITE to the SIP Server
using the ôtel:ö URI.
Step 5 - The SIP Server may query a location server (LS) if the
point of origination and the point of termination on the IP-based
network are in different ITAD, using one of the Front End Protocols
suggested within the TRIP framework [4] and maintained by the userÆs
ITSP, for the IP address of a Gateway for this telephone number.
Step 6 - The LS returns the IP address of the appropriate Gateway
for the destination number.
Step 7 - The SIP Server routes the call to the designated Gateway IP
address.
Step 8 - The Gateway completes the call through the PSTN to the
destination phone. It must respond to any signaling (e.g., ringing,
busy) from the PSTN and send the appropriate information back to the
call originator.
A protocol diagram of this call flow is contained in Appendix 2.
Lind Information - May 2002 7
ENUM Call Flows for VoIP Interworking November 2001
6. Calls to E.164 Numbers using Non-Geographic Numbering Plans (Global
Service Codes)
In general, all Global Services, including International Freephone,
International Premium Rate, and International Shared Cost, should
process in a similar manner. The first step in handling a Global
Service call is to determine, based on the number dialed, who the
appropriate service provider is that can process and complete the
call. In the case of PSTN-originated calls, that process is in place
today and should not be impacted by interworking with IP-based
networks. If the designated Global Service provider is an ITSP, then
the originating PSTN access provider should route the call to the
appropriate Gateway. The Global Service provider would then be
responsible for any necessary call processing and final number
translation using IN-based (i.e., SS7 signaling to an SCP), IP-based
(e.g., ENUM and/or other infrastructure used by the ITSP), or a
combination of facilities, as the service provider sees fit.
For IP-originated calls, the same general principle holds true.
Using the DNS, a query for the Global Service number as a FQDN
should return information that would allow the call to be routed to
a proxy, redirect, or other server operated by the Global Service
provider, which would then provide any call processing and
termination required by the Global Service customer. Again, the
service provider would be able to choose whether that processing
used IN-based, IP-based or a combination of facilities. Once the
necessary call processing was completed, the server could then
redirect or forward the call to the appropriate point of
termination.
7. Issues Surrounding Calls to Ported Numbers
For service provider portability [5], three scenarios need to be
examined that may impact processing of calls that go between the
PSTN and an IP-based network. The first is that a customer may
switch between two different PSTN service providers. As an example
in the US, a customer might switch between an ôincumbent local
service providerö and a ôcompetitive local service providerö or vice
versa. The second scenario is that a customer may switch between a
service provider on the PSTN to an ITSP (or vice versa). The third
scenario is that a customer may switch between two different ITSPs.
Other examples need to be developed that represent the number
portability requirements and implementations in other countries.
7.1 Calls originating on the PSTN
Calls under the first scenario should be handled already in todayÆs
PSTN environment. For the second scenario, there are issues about
what gets populated in the LNP database on the PSTN side of the
interface to route the call to a Gateway as described in section 5.1
Lind Information - May 2002 8
ENUM Call Flows for VoIP Interworking November 2001
above. In the US, where Location Routing Numbers (LRNs) is mandated
by regulation [6], it might be necessary for Gateways of the ITSP at
the destination end to be identified by a LRN.
For scenario 3, assuming the call reaches a Gateway, the change
should be reflected in a different URI for the destination
subscriber in the first DNS lookup. In our example in section 5.1,
step 4, the DNS might contain a different record now containing the
URI ôsip:jennyjones@newsipservice.fooö. The Gateway would then
resolve the URI in a different DNS to obtain the correct IP address
for the new SIP server.
7.2 Calls originating on an IP-based network
It appears that, under scenario 1, the primary impact would be that
the gateway for a given number might change or the gateway would
need to determine that the terminating PSTN service provider has
changed. The DNS might need to contain the LRN for the new
termination point. The LS would have to be responsive to point to
the new Gateway, if appropriate, for that destination number. The
Gateway, if the LRN was not available from the DNS, may have to
perform additional LNP queries on an IN-basis. If such queries are
not performed at or somewhere upstream from the Gateway, the call
may be routed to the wrong service provider or the ITSP may be
charged for the necessary LNP queries performed on its behalf.
Under scenario 2, it would appear that the change would occur within
the DNS in that instead of returning a ôtel:ö-based URI, the DNS
might now return a URI pointing to a SIP or H.323 terminal. Under
scenario 3, the call would not terminate on the PSTN and the DNS
would simply point to a different URI similar to the change
described in section 7.1 for scenario 3.
Lastly, for whatever solutions may be chosen and developed, the
solutions must meet any operational and performance requirements
mandated by regulation.
7.3 Further Work on Number Portability
ITU-T Question 3/2 is working on a draft new Supplement to
Recommendation E.370 [7]. This text should reflect information on
the impacts of interworking between the PSTN and an IP-based Network
when E.164 numbers are ported. The text should be shared with the
IETF as it becomes more stable.
8. Conclusions and Further Work
Use of ENUM functionality is fairly straightforward for simple call
flows. Unfortunately, the reality of todayÆs telecommunication
Lind Information - May 2002 9
ENUM Call Flows for VoIP Interworking November 2001
environment is that calling is far from simple. The issues
identified within this document include:
ò identification of the need to route a call from the PSTN to a
gateway at the edge of an IP-based network,
ò source of local number portability information for queries from
IP-based infrastructure,
ò mechanisms for transport of LNP information to the final
switching destination, (see draft-yu-tel-url-01.txt for one such
example).
While some of these issues may be outside the scope of ENUM, they
nevertheless have to be addressed if IP-based communication will be
viable. Between the IETF and the ITU, core competencies exist to
address these issues; continued cooperation will be beneficial.
9. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Falstrom, P., "E.164 number and DNS", RFC 2916, September, 2000
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
4 Rosenberg, J. and Schulzrinne, H., "A Framework for Telephone
Routing over IP", RFC 2871, June 2000
5 ITU-T Recommendation E.164, The international public
telecommunication numbering plan - Supplement 2: Number
Portability, November 1998 (see also draft-ietf-enum-e164s2-np-
00.txt)
6 Second Report and Order In the Matter of Telephone Number
Portability (FCC Docket No. 95-116), FCC 97-289, Adopted August
14, 1997 (see
http://www.fcc.gov/Bureaus/Common_Carrier/Orders/1997/fcc97289.tx
t)
7 ITU-T COM 2-R 80, "Recommendations requiring further development,
WP 1/2", March 2000
10. AuthorÆs Addresses
Steven D. Lind
AT&T
Bldg. 2, Room 2G25
180 Park Avenue
Lind Information - May 2002 10
ENUM Call Flows for VoIP Interworking November 2001
Florham Park, NJ 07932
U.S.A.
Phone: +1 973 236 6787
Email: sdlind@att.com
Lind Information - May 2002 11
ENUM Call Flows for VoIP Interworking November 2001
Appendix 1 û Protocol Diagram of the PSTN-to-IP Call Flow
Tel PSTN G/W DNS SIP SIP IP
Server Client Terminal
| | | | | | |
| Dial | | | | | |
|-------->| Setup | | | | |
| |-------->| ENUM | | | |
| | | Query | | | |
| | |-------->| Return | | |
| | | | URIs | | |
| | |DNS Query|<--------| | |
| | |-------->|Return IP| | |
| | | |addr of | | |
| | | |SIP Srvr | | |
| | | INVITE |<--------| | |
| | |---------+-------->| | |
| | | | Trying | | |
| | |<--------+---------| INVITE | |
| | | | |-------->| |
| | | | | Trying | |
| | | | |<--------|Incoming |
| | | | | |Call Ind |
| | | | | Ringing |-------->|
| | | | Ringing |<--------| |
| | Ringing |<--------+---------| | |
| Ringing |<--------| | | | |
|<--------| | | | |Off Hook |
| | | | | OK |<--------|
| | | | OK |<--------| |
| | Answer |<--------+---------| | |
| |Super- | | | | |
| | vision | | | | |
| Answer |<--------| | | | |
|<--------| | | | | |
| Both Way Voice | | Both Way RTP Media| |
|<--------+-------->|<--------+---------+---------+-------->|
| | | | | | |
Lind Information - May 2002 12
ENUM Call Flows for VoIP Interworking November 2001
Appendix 2 û Protocol Diagram of the IP-to-PSTN Call Flow
IP SIP SIP SIP-IN LNP DB DNS LS G/W PSTN Tel
Term Client Server Proxy
| | | | | | | | | |
| Dial | | | | | | | | |
|------>| ENUM Query | | | | | | |
| |-------+-------+-------+------->| | | | |
| | | | Returns URIs | | | | |
| |<------+-------+-------+--------| | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| | Trying| | | | | | | |
| |<------|Ported?| | | | | | |
| | |------>| LNP | | | | | |
| | | | Query | | | | | |
| | | |------>| | | | | |
| | | | LRN | | | | | |
| | | LRN |<------| | | | | |
| | |<------| | | | | | |
| | |-------+-------+--------+--->| | | |
| | | IP Address of Gateway | | | |
| | |<------+-------+--------+----| | | |
| | | | INVITE | | | | |
| | |-------+-------+--------+----+--->| | |
| | | | | Trying | | | | |
| | |<------+-------+--------+----+----|Setup| |
| | | | | | | |---->| Ring |
| | | | | | | |Ring-|------>|
| | | | | | | | ing | |
| | | | |Ringing | | |<----| |
| |Ringing|<------+-------+--------+----+----| | |
|Ringing|<------| | | | | | | |
|<------| | | | | | | |Offhook|
| | | | | | | |Ansr.|<------|
| | | | | | | |Super| |
| | | | | | | |visn.| |
| | | | | OK | | |<----| |
| | OK |<------+-------+--------+----+----| | |
|Answer |<------| | | | | | | |
|<------| | | | | | | | |
| | | | | | | | Both Way |
| | | Both Way RTP Media | | | Voice |
|<------+-------+-------+-------+--------+----+--->|<----+------>|
| | | | | | | | | |
Lind Information - May 2002 13
ENUM Call Flows for VoIP Interworking November 2001
Full Copyright Statement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
ôAS ISö basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Lind Information - May 2002 14