One document matched: draft-ietf-enum-usage-scenarios-00.txt
S. Lind
Internet Draft AT&T
Document: draft-ietf-enum-usage-scenarios-00.txt June 6, 2002
Category: Informational
ENUM Usage Scenarios
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 within the larger context of 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. Some
details are also provided for calls made using the ITU-defined
"Global Services" [3,4,5]. The impact of number portability within
the call scenarios is discussed. The objective of this document is
to identify areas where gaps exist in the provision of services and
suggest where protocol extensions for ENUM, SIP, TRIP, etc. are
needed.
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 [6].
Lind Information - Expires December 5, 2002 1
ENUM Usage Scenarios June 6, 2002
2.1 Definitions
ITSP - Internet Telephony Service Provider. An entity that provides
(originates and completes) voice 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 should take
the local dialing plan into account.
It is also envisaged that this document could be used by various
working groups within the IETF to identify areas where protocol
enhancements need to be developed. Some of these areas are pointed
out within this document. Other areas may become apparent after
further service requirements are identified by the ITU.
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 obtain and
transport number portability information within the call process
(e.g., 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.
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 applications 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
Lind Information - Expires December 5, 2002 2
ENUM Usage Scenarios June 6, 2002
addressed to their ôtelephone numberö (e.g., mailto:+1-973-236-
6787).
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 is more likely to 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 or |
| |dress translation| |may not 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 - Expires December 5, 2002 3
ENUM Usage Scenarios June 6, 2002
+--------+ +--------+ (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 - Expires December 5, 2002 4
ENUM Usage Scenarios June 6, 2002
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 - Expires December 5, 2002 5
ENUM Usage Scenarios June 6, 2002
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 - Expires December 5, 2002 6
ENUM Usage Scenarios June 6, 2002
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 at least 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 [7] and maintained by the userÆs
ITSP, for the IP address of a Gateway for this telephone number. As
input to the query, the server will supply the telephone number from
the ôtel:ö URI or the local routing number (LRN) if one was obtained
when and if a local number portability (LNP) query was done (see
section 7.2 for the discussion of LNP).
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,
Lind Information - Expires December 5, 2002 7
ENUM Usage Scenarios June 6, 2002
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. It
should be noted that this protocol diagram also contains some of the
number portability functionality not covered above.
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.
Figure 3 illustrates some of the steps necessary to provide such
services originating from an IP-based terminal. This example is just
one possible way of completing a global service call using ENUM.
Other possibilities exist and need to be explored in conjunction
with the Services Question (i.e., Q.3/2) in ITU-T Study Group 2
Step 1 - The originating customer dials an E.164 number. In the case
of a global service, the end user dials the international access
code for their country of origination (e.g., "011" in North America,
"00" in other locations) and the destination number.
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 the XYZ Company. The number that Jenny has
Lind Information - Expires December 5, 2002 8
ENUM Usage Scenarios June 6, 2002
for the XYZ Company is +800 123 456 7890. Jenny dials ô011 800 123
456 7890ö.
+--------+ +--------+ (5) +--------+ +--------+
| |(1,2,4) | |<......... .....>| DNS | (3,6)
| SIP |------->| SIP |---------+IP-based| +--------+
| Client |<......>| Server |<......... Network|
+--------+ +--------+ +---:--+-+
: |
(7) : |
v v
+--------+ (8) +---------+
| SCP |<.........>| Global |---->GW, PSTN,
+--------+ | Service | POTS Phone
| Proxy |
+---------+
---> Voice Path
...> Signaling Path
Figure 3
Global Service Call from IP-based Network to PSTN
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).
In the example, the SIP Client transforms the dialed number into a
FQDN of ô0.9.8.7.6.5.4.3.2.1.0.0.8.e164.arpaö.
Step 3 - The DNS returns any NAPTR service records associated with
the FQDN.
In the example, the DNS returns at least one record containing the
URI ôsip:8001234567890@provider.host.fooö.
Step 4 - The SIP Client initiates a SIP INVITE to the SIP Server
using the ôsip:ö URI.
Step 5 - The SIP Server looks up the address (A) record for the
specified host (e.g., ôprovider.host.fooö) in DNS.
Step 6 - DNS returns the IP address of a Global Service Proxy server
for the specified host.
Step 7 - The call is routed through the IP-based network to the
designated IP address.
Step 8 - The Global Service Proxy server uses the user name (i.e.,
"8001234567890") as well as interacting with the originating SIP
client or server to collect any necessary information (e.g., time of
day, place of origin) to process the call. The Global Service Proxy
may have to interact with some data store of service information to
Lind Information - Expires December 5, 2002 9
ENUM Usage Scenarios June 6, 2002
know how to route the call. In the illustration, the data store is a
Signaling Control Point (SCP) located in the signaling path of the
PSTN.
The data store may return various pieces of routing information
including an International Routing Address (INRA) and a Serving
Service Provider Identity. This information can then be used by the
Global Service Proxy to complete the call via a gateway to the
appropriate destination on the PSTN. ITU-T Question 2/2 is working
on the provision of routing information for calls on an IP-based
network [8].
A protocol diagram of this call flow is contained in Appendix 3.
7. Issues Surrounding Calls to Ported Numbers
Portability issues exist whether or not ENUM is used during the call
processing. There are three types of number portability: service
provider portability, geographic portability, and service
portability. This document will only deal with service provider
portability as it is the one type that is most likely to be
implemented.
For service provider portability [9], 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
above. In the US, where Location Routing Numbers (LRNs) is mandated
by regulation [10], 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
Lind Information - Expires December 5, 2002 10
ENUM Usage Scenarios June 6, 2002
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
a different gateway for a given number might be used 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
SIP Server or 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 by the PSTN. It is important that the LRN be carried forward
from the point at which it is obtained in order for the PSTN to know
that a portability query has been done.
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 [11]. 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
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 (this work, if necessary,
would be on the PSTN),
Lind Information - Expires December 5, 2002 11
ENUM Usage Scenarios June 6, 2002
ò Source of local number portability information for queries
(probably as an extension to the SIP protocol) from IP-based
infrastructure, and
ò mechanisms for transport of LNP information to the final
switching destination, (see draft-yu-tel-url-01.txt for one such
example of a proposed SIP extension).
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 ITU-T Recommendation E.152, International Freephone Service,
February 2001
4 ITU-T Recommendation E.154, International Shared Cost Service,
March 1998
5 ITU-T Recommendation E.155, International Premium Rate Service,
March 1998
6 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
7 Rosenberg, J. and Schulzrinne, H., "A Framework for Telephone
Routing over IP", RFC 2871, June 2000
8 ITU-T draft new Recommendation E.INRA.IP, Interworking of Routing
Addresses and IP-Nmaes/Addresses
9 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)
10 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.txt
)
Lind Information - Expires December 5, 2002 12
ENUM Usage Scenarios June 6, 2002
11 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
Florham Park, NJ 07932
U.S.A.
Phone: +1 973 236 6787
Email: sdlind@att.com
Lind Information - Expires December 5, 2002 13
ENUM Usage Scenarios June 6, 2002
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 - Expires December 5, 2002 14
ENUM Usage Scenarios June 6, 2002
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 |<------| | | | | |
| | |<------| | | | | | |
| | | LS Query for Gateway | | | | |
| | |-------+-------+--------+--->| | | |
| | | 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 - Expires December 5, 2002 15
ENUM Usage Scenarios June 6, 2002
Appendix 3 û Protocol Diagram of the IP-to-PSTN Freephone Service Call
Flow
IP SIP SIP FFS FFS DB DNS LS G/W PSTN Tel
Term Client Server Proxy
| | | | | | | | | |
| Dial | | | | | | | | |
|------>| ENUM Query | | | | | | |
| |-------+-------+-------+------->| | | | |
| | | | Returns URIs | | | | |
| |<------+-------+-------+--------| | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| | Trying| | | | | | | |
| |<------|INVITE | | | | | | |
| | |------>| | | | | | |
| FFS Processing | FFS | | | | | |
|<------+-------+------>| Query | | | | | |
| | | |------>| | | | | |
| | | | INRA, | | | | | |
| | | | SSPI | | | | | |
| | | |<------| | | | | |
| | | | LS Query for Gateway| | | |
| | | |-------+--------+--->| | | |
| | | |IP Address of Gateway| | | |
| | | |<------+--------+----| | | |
| | | | INVITE | | | | |
| | | |-------+--------+----+--->| | |
| | | | | Trying | | | | |
| | | |<------+--------+----+----|Setup| |
| | | | | | | |---->| Ring |
| | | | | | | |Ring-|------>|
| | | | | | | | ing | |
| | | | |Ringing | | |<----| |
| | |Ringing|<------+--------+----+----| | |
| |Ringing|<------| | | | | | |
| |<------| | | | | | | |
|Ringing| | | | | | | | |
|<------| | | | | | | |Offhook|
| | | | | | | |Ansr.|<------|
| | | | | | | |Super| |
| | | | | | | |visn.| |
| | | | | OK | | |<----| |
| | | OK |<------+--------+----+----| | |
| | OK |<------| | | | | | |
|Answer |<------| | | | | | | |
|<------| | | | | | | | |
| | | | | | | | Both Way |
| | | Both Way RTP Media | | | Voice |
|<------+-------+-------+-------+--------+----+--->|<----+------>|
| | | | | | | | | |
Lind Information - Expires December 5, 2002 16
ENUM Usage Scenarios June 6, 2002
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 - Expires December 5, 2002 17
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:19 |