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