Internet DRAFT - draft-bartosiewicz-enterprise-enum
draft-bartosiewicz-enterprise-enum
Internet Draft Andrzej Bartosiewicz
draft-bartosiewicz-enterprise-enum-01.txt NASK
September 03, 2004
Expires in six months
Intended status: Informational
Cost optimization based on Enterprise-ENUM
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This paper presents an extension of NAPTR Resource Records and an
application of the local DNS (called in further part of this
document "Enterprise -ENUM") in order to keep information required
for costs optimization of telecommunication connections. The paper
includes also all neccesary alghoritms.
The optimization should cover the cost reduction through the
selection of cheapest form of telecommunication connections for
the calling party (a person initializing a telecommunication
connection).
Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [9].
Introduction
Currently, the selection of the form and way of establishing
connection assumes that the caller selects the way of connection
through the selection of an operator (by whom a telecommunication
connection will be initiated - it's usually fixed phone operator,
mobile network operator or access to VoIP trough the Internet
Service Provider). At the same time, the calling party selects
a service identifier (especially a phone number) of a called person,
by whom the connection will be finished. Accessible forms of contact
depend on operators with whom the Calling Party has contracts and of
operators' services that are used by the called person.
In an optimal establishing of telecommunication connection the biggest
obstacles are as follows:
1. Calling Party selects the only one known way of connection's
initiation, which means that in the local phone directory there is
the only one telephone number by the certain person.
2. Calling Party selects the simplest by its side form of contact
(for example: mobile phone instead of VoIP connection).
3. Calling Party does not have knowledge about valid price-lists
(telecommunication rates), then contacts another side in the first
possible way.
4. Calling Party does not try to start a connection in the cheapest
way, like for instance VoIP, but it not always result in successful
connection. Instead of that, the Calling Party selects the most
possible and effective form of contact (telephone connection),
and usually there is a mobile phone number.
Additionally, in everyday communication one of the biggest obstacles is
a problem of identifiers used for contacts (like telephone numbers, Fax,
www addresses, e-mail or postal addresses). The change of numbers can be
connected with a change of telephone numbers (for example as a result of
a postal address change) or with the change of the operator. This problem
is especially increasing in those countries, where the number portability
hasn't been implemented or when an implementation of that mechanism was
not fully completed.
Concept of the solution based on Enterprise-ENUM.
In order to make an optimal choice of the way of connection, the user
(subscriber) can use information included in DNS (see [7],[8]) in form of
ENUM domains and NAPTR records (see [2],[3],[4],[6]). The public available
ENUM base (User-ENUM) includes information regarding accessible for the
subscriber forms of contact as well as information about preferred forms
of contact. Unfortunately, the information regarding preferred forms of
contact shows only preferences of the called person, not preferences of
a person who initiated a connection. That is why this information could
be not adequate for The Caller.
The assumption of solution presented in this document is made as follows:
on the basis of the history of established connections as well as
information about actual and obligatory telecommunications rates,
a switchboard (or external to it module) will analyze data and the results
(preferences regarding contacts) will be saved in the local DNS. In case
when the subscriber (The Caller) initiating a connection, would inquire
the ENUM database about available forms of contact (and this inquiry will
be transferred to Enterprise -ENUM instead to User -ENUM database),
The Caller will get an information, which will let him to choose the
cheapest form of telecommunication connection.
Remark: Assuming that on the basis of previous established connections
and valid pricelists for telecommunication services, the costs of
connections are analyzed and on that basis Enterprise-ENUM database is
filled. The method of optimization as well as information structure of
databases concerning established connections and telecommunication rates
is not a part of presented paper and will be described in another
document. In this document, in chapter "Overview of Enterprise-ENUM
updating algorithm" is only presented a general overview of the algorithm
which describes updating of data included in local DNS (Enterprise-ENUM).
Scheme
Optimization solution is based on a scheme containing the following
logical elements:
-Switchboard (e.g. PBX)
-Optimization Module
-Connections Database containing detailed information about accomplished
and not accomplished connections.
-Tariff Database: telecommunication rates paid by the calling party and
by the called party
-Enterprise-ENUM storing results of optimization process. Enterprise-ENUM
Database is placed in local tree containing registry of ENUM domains
together with NAPTR records (Number Authority Pointer Records)
-User-ENUM Base: DNS Database within so called "golden tree"- public DNS.
It is important to mention, that DNS data bases ("User-ENUM" and
"Enterprise-ENUM") as well as other bases (of connections, tariffs,
operators) are not physically connected with each other. We assume that
switchboards will be gradually integrated with the DNS solutions.
Connections Database
Connections Database stores information about the executed connections
containing:
-Called Party identifier (telephone number or SIP address)
-Exact time of the beginning of a conversation
-Exact time of the end of a conversation
-Reference to the position in the price list (Tariff Database)
-Information about eventual remaining limit from subscription (time of
"free" phone conversation within subscription, data transfer within
subscription etc.)
-Quality of the connection
-Calling Party Identifier (telephone number or SIP address)
-Flag showing whether a given number was taken for analysis by Optimization
Module.
Tariff Database
Tariff Database will store information about current telecommunications
tariffs given by operators providing communications services within signed
agreements. Tariff Database does not have to store an information concerning
other costs: subscription fees which are not dependant from actually
executed services, activation or discontinuation of service (end of service)
fees.
In the Tariff Database can be stored the following information:
-Identifier of the Telecom Operator
-Name of the tariff
-Way of timing (quantity of seconds per a tariff unit)
-Accounting period (optional)
-Quantity of pre-paid tariff units included into subscription (with regard to
the way of timing) and information about specific way of timing of units
included into subscription (for example, what happens with units which
haven't been used in certain accounting period and remain untapped)
-Peak hours (period of time within 24 hours and definition of days of a week
when pick hours oblige, for example within the working days)
-Hours beyond peak hours (remarks as above)
-Other hours (for instance night hours) or division into 24 sections of hour
sections within 24 hours
-Cost of connection within a defined time periods, divided into:
-Connections within the network of one particular Operator
-Connections with other networks
-Connections with selected numbers (numbers enumerated in the contract with
operator) or "corporate" connections
-Connections to operator's services (i.e. voice mail, call centers, news
services)
-Connections to other services rated in a different way than left services.
-WAP connections and data transmition (UMTS/EDGE/GPRS/CDMA)
Availability of "Enterprise-ENUM" database
"Enterprise-ENUM" is based on that same mechanism as "User-ENUM". The only
difference between them is in their availability. In case of "user-ENUM"
an access is unlimited (public). For "Enterprise-ENUM" database an access
is not public, and particularly an access is possible only for certain
persons (e.g. employees of the company that owns that database).
"Enterprise -ENUM" could be considered in some cases as an "Infrastructure
ENUM" in accordance with description given by ETSI [1].
Thanks to that approach it is possible to:
a. Consider saved information as confidential information. We assume,
that data in "Enterprise-ENUM " database might have a confidential
character because of included contacts to subscribers, with whom we have
been contacted. On basis of this data, it would be possible to conclude
other information, for instance preferred way of communication. At the
same time it would give information about habits of subscriber.
b. Save information in DNS, which could be valuable only in particular
part of the network and they might not be applicable for persons in other
environment (other point of network, serviced by other provider and
according to his pricelist)
Content of "User-ENUM" and content of "Enterprise -ENUM".
"User-ENUM" stores one ENUM domain and set of NAPTR records for every
subscriber. An exemplary record taken from "User-ENUM" database:
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 10
"up" "tel+E2U" "!^.*$!tel:+48225231200!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"up" "tel+E2U" "!^.*$!tel:+48225231204!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 10
"up" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 20
"up" "mailto+E2U" "!^.*$!email: info@nask.biz!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 30
"up" "tel+E2U" "!^.*$!tel:+48225231395!".
For every subscriber, Enterprise-ENUM stores as many domains as
identifiers of services (phone numbers) he has. At the same time, for
every domain name NAPTR records describing other forms of contact are kept
An exemplary record in "Enterprise-ENUM" database related with mentioned
above record in "User-ENUM" database:
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50
"5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231200!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231204!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100
"oup" "tel+E2U" "!^.*$!tel:+48225231395!".
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50
"5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!".
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231200!".
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231204!".
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100
"oup" "tel+E2U" "!^.*$!tel:+48225231395!".
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 100 50
"5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!".
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231200!".
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10
"9oup" "tel+E2U" "!^.*$!tel:+48225231204!".
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 100
"oup" "tel+E2U" "!^.*$!tel:+48225231395!".
Extensive meaning of NAPTR fields in "Enterprise-ENUM"
Format (The packet format of the NAPTR RR) of the NAPTR record is not
changed and is in accordance with [4]. The packet format for the NAPTR
record is as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ORDER /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PREFERENCE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
We assume, that in NAPTR records we store following additional data
related with every contact:
-[ORDER] of initiating a connection regarding to order of choosing
contacts (in accordance with an order of choosing NAPTR records).
Preferences of the Caller do not have to be the same as preferences of
the called person which are to be found in "public" DNS (User ENUM).
-[PROBAILITY] probability of correct initiation of connection with a
certain telephone number (remark: it refers to every NAPTR record, also
NAPTR record for an e-mail address, being the integer in range from 0 to
100.
-[QUALITY] Overall quality indicator from the point of view of the Caller.
Mentioned above indicator will be marked with a flag having value from 0
to 9 (range limited by RFC 3403), where "0" indicates not acceptable
quality of connection, and "9" indicates an "ideal" connection (it means
with a constant and acceptable delay, without lost of packets etc.).
The quality of connection can be determined on the basis of any parameter
identifying the quality of connection; in particular for VoiP it could be
the parameter MOS-LQ (Mean Opinion Score Listening Quality) or MOS-CQ
(Mean Opinion Score Conversional-Quality). Parameters MOS-LQ and MOS-CQ
are in the range from 1 to 5. For MOS-LQ and MOS-CQ the value [QUALITY]
will be defined with following formula:
[QUALITY]=MOS-LQ *2-1 or [QUALITY]=MOS-CQ *2-1
Fields described in this paragraph will be coded in existing fields of
NAPTR RR in the following way:
-[ORDER] field of modified standard will be saved as [ORDER] field of
an existing standard (the meaning of that field will be changed).
-[PROBABILITY] field of modified standard will be saved as the [PREFERNCE]
field of existing standard (the meaning of this field will be changed)
-[QUALITY] field will be changed to a flag (integer from 0 to 9), placed
in [FLAGS] field of existing standard.
Updating of DNS zone files for Enterprise-ENUM
Another problem is the definition of DNS zone files for Enterprise-ENUM
updating frequency. Having limited (particularly it might be one) number
of DNS servers for "Enterprise-ENUM", and moreover definitely smaller
number of NAPTR records in comparison with "User-ENUM" (in this case the
number of NAPTR records depends on the number of subscribers with whom
the company contacts and on number of unique contacts to subscribers),
DNS zone files can be updated many times within 24 hours. It is possible
to make general estimations in order to compare "User-ENUM" with
"Enterprise-ENUM": Assuming that for every ENUM domain five NAPTR RRs
are existing (one record for mobile number, home number, fax, e-mail
address and address for SIP [5]).Simplifying, we can assume, that
the company contacts 10 000 subscribers, what gives 50 000 NAPTR records.
For comparison, in public DNS we can expect 27 millions domains ENUM (the
number of telephones in Poland in the year 2003), what makes 135 millions
of NAPTR RRs. As we can see from this comparison, use of the local DNS
for ENUM gives an advantage because of possible much easier updating of
zone files ("Enterprise-ENUM" is potentially four times smaller than
the "User-ENUM").
Optimization Algorithm using Enterprise-ENUM database
Optimization algorithm contains the following elements:
-Enterprise-ENUM updating algorithm,
-Algorithm of record selection from Enterprise-ENUM database
-Establishment of connection alghoritm
Establishment of connection
Before a connection will be established using records in DNS base, DNS base
is filled with data resulted from activities of an optimization algorithm.
Detailed information regarding functioning of algorithms will be presented
below.
During establishing of connection, switchboard (telephone exchange)
checks Enterprise - ENUM and User - ENUM databases according to the
following algorithm:
Establishment of connection
1. The Switchboard MUST query the "Enterprise-ENUM" database.
2. In response a switchboard receives a list of NAPTR records or
information about lack of record in DNS.
3. The switchboard is trying to establish a connection, considering the
sequence of NAPTR records by including parameters saved in fields: ORDER
and PREFERENCE. When connection is established, an algorithm is finished.
4. If there is a lack of record in Enterprise-ENUM database, the
switchboard MUST query User-ENUM database.
5. As a response, switchboard receives a list of NAPTR records or
information about lack of record in DNS.
6. Switchboard is trying to establish a connection, considering the
sequence of NAPTR records by including parameters saved in fields: ORDER
and PREFERENCE.
Enterprise-ENUM database has to be filled in with correct data, before it
will be used for optimization.
Actualization algorithm of Enterprise-ENUM database
1. Optimization Module selects first record from connections database
(executed connection) and retrieves a contact (a telephone number, SIP
addressee) to a subscriber.
2. For a given identifier, Optimization Module retrieves from "User-ENUM"
Database the list of available NAPTR records.
An example of retrieved NAPTR records:
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 10 "up" "tel+E2U"
"!^.*$!tel:+48225231200!"
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "up" "tel+E2U"
"!^.*$!tel:+48225231204!"
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 10 "up" "sip+E2U"
"!^.*$!sip:204@obelix.nask.waw.pl!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 20 "up" "mailto+E2U"
"!^.*$!email: info@nask.biz!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 30 "up" "tel+E2U"
"!^.*$!tel:+48225231395!".
3. Optimization Module retrieves from Connection Database history of all
particular phone connections, performed by particular Subscriber (Called
Party), regarding each identifier (phone number, SIP address) received in
step 2 of this algorithm. As the result, there is a list of all contacts
(history of calls) with a particular subscriber (Called Party) realized
in every possible way, that were stored in the Connection database.
4. On the basis of data stored in the Connection Database and the Tariff
Database, sequence of contacts to a particular subscriber (called party) is
being determined (using the assigned methodology i.e. Bayesian networks,
Hidden Markov Model, statistical methods), from the most effective to the
least effective. The sequence is determined independently for cost,
probability and quality. This stage of an algorithm , as critical for the
whole solution, is described in more details in the chapter "Estimation
of connections sequence".
5. All identifiers with determined parameters are saved in a zone file in
the "Enterprise-ENUM" database in accordance with fields description
(see subsection "Extensive meaning of NAPTR fields in Enterprise-ENUM").
For every identifier, Internet domain is created and for this domain NAPTR
records are created, related with all other contacts (e.g. for 3 numeric
contacts there are 3 domains and totally 9 NAPTR records being created)
An exemplary record in the "Enterprise ENUM" database corresponding with
a list of retrieved contacts (record for email address is passed over;
for each number identifier are created domains with assigned NAPTR
records).
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U"
"!^.*$!sip:204@obelix.nask.waw.pl!"
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231200!"
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231204!"
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U"
"!^.*$!tel:+48225231395!".
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U"
"!^.*$!sip:204@obelix.nask.waw.pl!"
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231200!"
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231204!"
4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U"
"!^.*$!tel:+48225231395!".
0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U"
"!^.*$!sip:204@obelix.nask.waw.pl!"
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231200!"
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U"
"!^.*$!tel:+48225231204!"
5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U"
"!^.*$!tel:+48225231395!".
6. Optimization Module marks all contacts (calls) stored in the Connection
Database that has been completed with a given subscriber, in order to
omit these records within the next loop of the algorithm.
7. Optimization Module searches for another possible contact from Connection
Database and goes to step 2 of this algorithm. If there are no records to be
retrieved from the Connection Database, algorithm ends, saving the results
as a file of "Enterprise-ENUM" database.
Algorithm of record selection from Enterprise-ENUM database
1. A switchboard transfers to Optimization Module a telephone number
(contact) with which the calling party wants to be connected.
2. Optimization Module queries "Enterprise-ENUM". In response the
Optimization Module receives a list of NAPTR records or information about
the lack of record in DNS.
3. Simplified Optimization Module successively transmits to switchboard
contacts (identifiers) which may be connected to, considering fields:
ORDER and PREFERENCE. Simplified Optimization Module has no access to
"Tariff Base" and "Connections Base"
4. In case of the lack of record in Enterprise-ENUM, Simplified
Optimization Module queries User-ENUM database. In response, Simplified
Optimization Module receives a list of NAPTR records or information about
the lack of record in DNS.
5. Simplified Optimization Module successively transmits to switchboard
contacts (identifiers) which may be connected to, considering fields: ORDER
and PREFERENCE. In case of lack of record in DNS, Simplified Optimization
Module transmits reversibly to switchboard a telephone number which was
transmitted to switchboard at the beginning of the process.
6. After the connection is completed, data concerning this connection
(telephone number, parameter of quality of connection, duration of
connection) are recorded in the Connections Base (optionally).
Information contents of Enterprise ENUM database, before its adoption by
optimization, must be earlier filled in with the correct data. We assume
that on the ground of the Connections Base contents as well as content of
the Tariff Base, the Enterprise ENUM database is actualized in defined
time intervals. Additionally, we can optionally assume that after executed
connection (established according to algorithm of record selection from
Enterprise-ENUM database) the history of connection is recorded in the
Connections Base. More data in the Connections Base results in better
quality of data included in the Enterprise-ENUM database.
Estimation of connections sequence
Fundamental element of "Actualization algorithm for Enterprise-ENUM" and
of the whole problem of costs optimization using ENUM platform is a way of
a cost estimation related to a given subscriber. An Actualization Algorithm
has assumed in point 4, that on the base of data included in the
Connections and the Tariff Base, using given method, a sequence of contacts
to a given subscriber (by whom a connection is terminated from the point
of view of the calling party) is set. In this chapter possible methods of
setting such optimal sequence of contacts will be presented.
The algorithm operates on data retrieved from the Connections Base (history
of connections) concerning accomplished and not accomplished connections
with certain subscriber, taking into consideration the following parameters:
-Contact (telephone number compliant with E. 164 or an address)
-Exact time of the beginning of phone conversation (in case when an
estimation will be carried out with division into given intervals of
time)
-Exact time of the end of phone conversation
-Total time of phone conversation (optionally)
-Parameter defining the quality of connection (it may be whichever of many
possible ways of an estimation of quality of connection)
-Identifier of user initializing a connection (E.164 telephone number or
SIP address)
Basing on this an independent estimation of following parameters of
connections can be carried out, concerning:
-time of connection
-probability of correct connection
-quality of connections
An estimation may be carried out using different methods, for example.:
-Bayesian networks
-Meta- Bayesian Networks
-Hidden Markov Model
-Casual Networks
We shall consider whether an estimation of acertain parameter should be
carried out of given time intervals (for instance, an estimation of
connection time with division into 60-minutes intervals) or estimation
should be carried out without taking any notice of intervals of time in
which connections have been established. There is also possible to imagine
a situation, when given time intervals are: peak hours, time beyond peak
hours, not working days. Carrying out an estimation using Bayessian
network necessary to divide time of estimation process into 2 stages:
construction of a tree and conclusion. Carrying out an analysis, for
example using statistical method, the whole process could be achieved
in one step of an algorithm. A result of adoption of mentioned above
methods for every contact will be the following combination:
-Estimated time of conversation
-Estimated quality of conversation
-Estimated probability of establishing of connection
If additionally an estimation takes into consideration time intervals,
a combination will contain estimated values in context of given time
intervals.
Exemplary result of this stage of algorithm:
-contact: +48.606241570
-estimated time:
-78 seconds; peak hours
-23 seconds; beyond peak hours
-137 seconds; not working hours
The next stage will be the calculation of connection costs for estimated
values on the base of available records in the Tariff Base. An algorithm
has to consider following the parameters recorded in the Tariff Base:
-Way of timing (quantity of seconds in one tariff unit)
-Time intervals:
-Peak hours (time interval within 24 hours and definition of week days
when peak hours oblige, i.e. working days)
-Hours beyond peak hours (remarks as above)
-Other time intervals (i.e. night hours) or division into 24 time
intervals within 24 hours (60 minutes intervals)
-Cost of connection in defined time intervals with division into:
-Connections within net of a given operator
-Connections with other operators
-Connections with selected numbers, "corporation" connections
-Connections to other services rated in another way than left services
-WAP connection cost
Additionally an algorithm can take into account, for example:
-Quantity of tariff units included into subscription (considering way of
timing)
-Information about specific handling of units included into subscription
(for instance, what happens with units which were not used within the
concrete accounting period)
In this case the problem becomes complicated, because it's necessary to
estimate additionally the total time of calls and to carry out a
complicated analysis considering costs of single connections including
connections within the subscription as well as the cost of the whole bill
for using a particular tariff package(subscription).
The last element is creation of list of Contacts for certain Subscriber
considering estimated cost of phone conversation, quality of connection
and probability of establishing of connection.
IANA Considerations
This document introduces no new values for IANA registration
Terms and Definitions
Calling Party- The end user trying to establish a voice call by using an
E.164 number related to the called user.
Called Party - The end user related to the Identifier (i.e. E164 number)
given by the calling user.
Address - definition of telecommunication or IT subscriber address (in
accordance with E.164), addresses of VoIP subscribers ( SIP URL-adresses
[5]), addresses of applications like Instant Messenger etc.
SIP URL - address for VoIP connection using SIP. SIP URL takes a form
similar to a "mail to" form i.e. user@host. The user part is a user name
or a telephone number. The host part is either a domain name or a numeric
network address.
Operator - provider of telecommunication and IT services, which offers
different types of services, e.g. fixed (stationary) lines, mobile
telecommunications, VoIP etc.
Abbreviations and Acronyms
DNS: Domain Name System
IETF:Internet Engineering Task Force
ITU: International Telecommunication Union
NAPTR: Number Authority Pointer Record
RFC: Request For Comment (IETF related standard)
SIP: Session Initiation Protocol
RRs: (DNS) Resource Record
E.164: "The International Public Telecommunications Numbering Plan"
ENUM: TElephone NUmber Mapping - both a protocol and an IETF Working Group
ETSI: European Telecommunications Standards Institute
References
[1] "TS 102 055 Services and Protocols for Advanced Networks (SPAN);
Scenarios for User and Infrastructure ENUM"
the European Telecommunication Standards Institute
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC 3401, www.ietf.org,
February 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, www.ietf.org, February 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC 3403, www.ietf.org, February 2002.
[5] Handley, "SIP: Session Initiation Protocol", RFC 2543, www.ietf.org,
March 1999
[6] Bartosiewicz, A., "ENUM - how does it work" Newsletter ISOC-UK
http://www.england.isoc.org/newsletter/Issue-04-January-03.rhtm
[7] Mockapetris, P., "Domain names - implementation and specification",
STD 13, RFC 1035, www.ietf.org, November 1987.
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13,
RFC 1034, www.ietf.org, November 1987.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, www.ietf.org, March 1997
Copyright Statement:
Copyright (C) NASK 2004. All Rights Reserved.
Author address:
Andrzej Bartosiewicz
Head of DNS Dept.
NASK
18 Wawozowa Str.
PL-00-796 WARSAW
Andrzej.Bartosiewicz@NASK.pl
