Method, device and system for judging call type

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is a continuation of International Application No. PCT/CN2009/074593, filed on Oct. 23, 2009, which claims priority to Chinese Patent Application No. 200810170764.X, filed on Oct. 24, 2008 and Chinese Patent Application No. 200910150738.5, filed on Jun. 30, 2009, all of which are hereby incorporated by reference in their entireties.

FIELD OF THE INVENTION

0002The present invention relates to the field of communication technologies, and in particular, to a method, device, and system for judging a call type.

BACKGROUND OF THE INVENTION

0003The Federal Communications Commission (FCC) of America requires that the switches in charge of voice calls in North America should judge the call type. Call types include Local, Local Toll, Long Distance, and International. The switches in charge of voice calls in North America come in two types: Public Switched Telephone Network (PSTN) switch and Voice over Internet Protocol (VoIP) switch.

0004The North America Numbering Plan (NANP) involves massive data (hundreds of thousands of lines), which occupies enormous memory resources in the switches and results in a lot of retrievals.

0005The plan information of the calling number and the called number, namely, Local Access and Transport Area (LATA) and Rate Center (RC) information corresponding to the calling number and the called number, is essential for judging the call type. The FCC divides America (including Canada and Bermuda) into scores of LATAs, and each LATA governs scores of or even over a hundred RCs. Each number belongs to a specific RC.

0006For the purpose of judging the call type accurately, the switch queries for the LATA and the RC of the calling number and the called number respectively, and obtains the call type of the call according to a judgment logic. According to the FCC specifications, the first six digits of a number, namely, NPA-NXX of a North America number, can uniquely determine the LATA and the RC of the number. However, there are hundreds of thousands of NPA-NXXs.

0007The number and its LATA and RC are not constant. A special organization in North America publishes the latest data periodically in the form of Local Exchange Routing Guide (LERG) files, which are generally LERG6.DAT and LERGINS.DAT text files.

0008Accordingly, the data needs to be imported into every switch, and updated into the local database, which leads to high costs of maintenance.

0009What described above are only examples, and definitely regions are not limited to North America. In regions other than North America, the same problems occur in similar scenarios.

SUMMARY OF THE INVENTION

0010Embodiments of the present invention provide a method, device and system for judging a call type. A number information storage server stores and manages the number plan information, thus reducing the maintenance costs; and the method, device and system for judging the call type enable judging of the call type of a terminal.

0011The objectives of the present invention are fulfilled through the following technical solution:

0012A method for judging a call type includes:

0013receiving a call request from a calling terminal, where the call request carries a calling terminal number and a called terminal number;

0014querying a number information storage server for plan information of the calling terminal number and/or the called terminal number according to the call request; and

0015judging a call type of a call service corresponding to the call request according to the plan information of the calling terminal number and the called terminal number.

0016A call control server includes:

0017a receiving module, configured to receive a call request from a calling terminal, where the call request carries a calling terminal number and a called terminal number;

0018a first querying module, configured to query a number information storage server for plan information and/or plan-related information of the calling terminal number and/or the called terminal number in the call request received by the receiving module; and

0019a judging module, configured to judge a call type of a call service corresponding to the call request, according to the plan information and/or plan-related information of the calling terminal number and the called terminal number, where the plan information and/or plan-related information is obtained by the first querying module.

0020A number information storage server includes:

0021a storing module, configured to store plan information and/or plan-related information of a number;

0022a receiving module, configured to receive a message for querying for plan information of a calling terminal number and/or a called terminal number;

0023a querying module, configured to: query the storing module for the plan information of the calling terminal number and/or the called terminal number, according to the message received by the receiving module; and/or query the storing module for plan-related information, according to the plan information of the calling terminal number and/or the called terminal number; and

0024a sending module, configured to: send the plan information of the calling terminal number and/or the called terminal number, and/or send the plan-related information, where the plan information and the plan-related information are obtained by the querying module.

0025A call control network includes:

0026a number information storage server, configured to store plan information and/or plan-related information of a number; and

0027a call control server, configured to: query the number information storage server for plan information of a calling terminal number and/or a called terminal number of a call service, and judge a call type of the call service according to the plan information and/or plan-related information.

0028The technical solution under the present invention brings these benefits: Because a number information storage server stores and manages the plan information and/or plan-related information of the number, it is not necessary for every call control server to store the relevant data, and the maintenance costs are reduced when the call type of the terminal is judged.

BRIEF DESCRIPTION OF THE DRAWINGS

0029<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a flowchart of a method for judging a call type according to a first embodiment of the present invention;

0030<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram of a structure of a call control network according to a second embodiment of the present invention;

0031<figref idref="DRAWINGS">FIG. 3</figref> is a schematic diagram of relations between LATAs and RCs according to an embodiment of the present invention;

0032<figref idref="DRAWINGS">FIG. 4</figref> is schematic diagram of a flowchart of a method for judging a call type according to a third embodiment of the present invention;

0033<figref idref="DRAWINGS">FIG. 5</figref> is a schematic diagram of a structure of a call control network for judging a call type in an IMS network according to an embodiment of the present invention;

0034<figref idref="DRAWINGS">FIG. 6</figref> is a schematic diagram of a flowchart of a method for judging, by an S-CSCF, a call type according to a fourth embodiment of the present invention;

0035<figref idref="DRAWINGS">FIG. 7</figref> is a schematic diagram of a flowchart of a method for judging, by an AS, a call type according to a fifth embodiment of the present invention;

0036<figref idref="DRAWINGS">FIG. 8</figref> is a schematic diagram of a flowchart of a method for judging a call type according to a sixth embodiment of the present invention;

0037<figref idref="DRAWINGS">FIG. 9</figref> is a schematic diagram of a flowchart of a method for judging a call type according to a seventh embodiment of the present invention;

0038<figref idref="DRAWINGS">FIG. 10</figref> is a schematic diagram of a flowchart of a method for judging, by an I-CSCF/S-CSCF/AS, a call type according to an eighth embodiment of the present invention; and

0039<figref idref="DRAWINGS">FIG. 11</figref> is a schematic diagram of a flowchart of a method for judging, by an HSS/HLR, a call type according to a ninth embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

0040The embodiments of the present invention are detailed below with reference to the accompanying drawings.

0041The inventor finds the following problems in the prior art: The number plan information needs to be imported and maintained in every call control device/switch; once the number plan information needs to be updated, every call control device/switch on the existing network needs to update the number plan information, which leads to high costs of maintenance and increases the probability of errors caused by asynchronous data on different call control devices/switches in the data update process; moreover, the size of the number plan information is enormous and generally there are hundreds of thousands of data entries, which need to be stored on every call control device/switch, thus wasting the storage space and increasing the hardware overhead of every call control device/switch.

0042In view of the problems in the prior art, embodiments of the present invention introduce a number information storage server to the existing communication network system to perform centralized storage and uniform management for the number plan information and/or plan-related information, thus reducing costs of hardware and maintenance. Further, embodiments of the present invention provide a method, device, and system for judging a call type by applying the number information storage server, so as to realize judging a call type of a terminal.

0043The technical solution under the present invention is expounded below with reference to embodiments and accompanying drawings. Evidently, the embodiments are exemplary only, without covering all embodiments of the present invention. All other embodiments, which can be derived by those skilled in the art from the embodiments given herein without creative efforts, shall fall within the protection scope of the present invention.

0044A method for judging the call type is provided in the first embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the method includes the following steps:

0045Step S<b>101</b>: Receive a call request from a calling terminal, where the call request carries a calling terminal number and a called terminal number.

0046Step S<b>102</b>: Query a number information storage server for plan information of the calling terminal number and/or the called terminal number according to the call request.

0047This step may include the following detailed operations:

0048through a query interface, a query request that carries the calling terminal number is sent to the number information storage server, and a query response that carries the plan information of the calling terminal number is received from the number information storage server; and/or

0049through the query interface, a query request that carries the called terminal number is sent to the number information storage server, and a query response that carries the plan information of the called terminal number is received from the number information storage server.

0050It should be noted that, the plan information of the calling terminal number and the plan information of the called terminal number are generally queried and obtained in two attempts of query. In practical applications, to save network resources and reduce interactions, the query step may be simplified in the following two ways:

0051Scenario 1: When the calling terminal is registered, a call control server stores the plan information of the calling terminal number directly.

0052In this case, the query process in this step is modified as:

0053obtaining the locally stored plan information of the calling terminal number; and

0054querying and obtaining the number information storage server for the plan information of the called terminal number.

0055Obtaining the locally stored plan information of the calling terminal number is retrieving the information from the call control server directly, without the need of querying the number information storage server.

0056Scenario 2: After the plan information of the calling terminal number and the called terminal number is queried and obtained in step S<b>102</b>, the plan information of the calling terminal number and the called terminal number is stored directly. In this case, in the subsequent call setup process, the step of querying for the plan information in the process of judging the call type is modified as:

0057obtaining the locally stored plan information of the calling terminal number and querying the number information storage server for plan information of another called terminal number, when receiving a call request sent by the calling terminal to said another called terminal subsequently; or

0058obtaining the locally stored plan information of the called terminal number and querying the number information storage server for plan information of another calling terminal number, when receiving a call request sent by said another calling terminal to the called terminal subsequently; or

0059obtaining the locally stored plan information of the calling terminal number and the called terminal number, when receiving a call request sent by the calling terminal to the called terminal subsequently.

0060The variations of the solution above are put forward because in the basic solution of this step, an ordinary call relates to at least two attempts of querying for the plan information, which reduces the efficiency to some extent. Therefore, the embodiments of the present invention put forward an improved solution. A buffer of query records is introduced to reduce the times of querying for the plan information. Meanwhile, at the time of registration, the registered user information is retrieved from the number information storage server and stored. If the calling terminal and the called terminal communicate with a same call control server, the calls between the calling terminal and the called terminal involve no operation of querying the number information storage server.

0061Step S<b>103</b>: Judge a call type of a call service corresponding to the call request, according to the plan information of the calling terminal number and the called terminal number.

0062It should be noted that in the foregoing embodiment, the call control server judges the call type of the call service corresponding to the call request, according to the plan information of the calling terminal number and the called terminal number. In another embodiment of the present invention, the call control server may judge the call type of the call service corresponding to the call request, according to the plan information of the calling terminal number, the plan information of the called terminal number, and the plan-related information (Local RC). The plan-related information may be stored locally or stored in a number information storage server. When the plan-related information is stored in the number information storage server, the plan-related information can be queried from the number information storage server.

0063This step may include the following scenarios:

0064Scenario 1: A user plan-related request is sent to the number information storage server according to the plan information of the calling terminal number and the called terminal number; and the call type of the call service corresponding to the call request is judged according to a user plan-related response sent by the number information storage server.

0065Specifically, the plan-related information is stored in the number information storage server, and the call control server sends a user plan-related request to the number information storage server according to the plan information of the calling terminal number and the called terminal number; the number information storage server finds the plan-related information and sends a user plan-related response; and the call control server judges the call type of the call service corresponding to the call request according to the user plan-related response.

0066Scenario 2: A call request that carries the calling terminal number and the called terminal number is sent to the number information storage server, and the call type of the call service corresponding to the call request is received from the number information storage server.

0067Specifically, the call control server sends the call request that carries the calling terminal number and the called terminal number to the number information storage server, and the number information storage server finds the plan information of the calling terminal number and/or the called terminal number according to the call request. After obtaining the plan information of the calling terminal number and/or the called terminal number, the number information storage server may obtain the plan-related information according to the plan information. The number information storage server determines the call type according to the plan-related information, and returns a query result which carries the call type of the call service corresponding to the call request.

0068In practical applications, to save network resources and reduce interactions, the foregoing query step may be simplified in the following way:

0069Scenario 3: The plan information of the calling terminal number, the plan information of the called terminal number, and the plan-related information are stored directly after they are obtained. Therefore, in the subsequent call setup process, the query for the plan information of the calling terminal number, the plan information of the called terminal number, and the plan-related information can be simplified. For example, a buffer of query records is introduced to reduce the times of querying for the plan information and the plan-related information. Meanwhile, at the time of registration, the registered user information is retrieved from the number information storage server and stored into the call control server. If the calling terminal and the called terminal communicate with the same call control server, the calls between the calling terminal and the called terminal involve no operation of querying the number information storage server.

0070After completion of step S<b>103</b>, the method includes an update process, as detailed below:

0071When the calling terminal number and/or the called terminal number is updated, the call control server queries the number information storage server for the plan information corresponding to the updated calling terminal number and/or the called terminal number, and/or the plan-related information.

0072The call control server judges the call type of the call service corresponding to the call request, according to the plan information of the updated calling terminal number and called terminal number, and/or the plan-related information.

0073The number information storage server mentioned in this embodiment may be a single number information storage server, or a number information storage server pool including more than one number information storage server, which shall not be constructed as limitations to the protection scope of the present invention. The same is applicable throughout this document, and will not be repeated described hereinafter.

0074Further, depending on the application scenario, the preceding technical solution may be improved into the following two solutions:

0075Improved solution 1: In the number information storage server, the corresponding plan parameter such as routing number is configured for the special service number (such as North America N11 service).

0076N11 is a generic term of special numbers of North America, and is embodied as 211, 311, 411, 511, 611, 711, 811, and 911. In North America, such numbers bear special meanings. They are taken as examples here for ease of description. The details of the services of such special numbers are not further given here.

0077When the called terminal number is a preset service number, the call control server queries the number information storage server for the plan parameter corresponding to this service number. In the query process, the information that needs to be sent to the number information storage server carries the calling terminal number because such services usually relate to the location of the calling terminal number.

0078Taking the North America communication control network as an example, the process of implementing improved solution 1 is described below:

0079The LATA and RC information is stored into an E164 Telephone Number Mapping (ENUM) server together, and at the same time, the special service numbers such as N11 corresponding to the numbers are stored into the ENUM server together in the same way.

0080It should be noted that, in the North America communication control network, the ENUM server is the number information storage server in the embodiments mentioned above. The name of this server shall not be constructed as limitations to the protection scope of the present invention.

0081Taking the community service number 211 in North America as an example, when a user dials 211, the network translates 211 into a plan parameter, namely, a routable 10-digit North America Numbering Plan (NANP) number. The translation is based on the LATA and RC information corresponding to the calling terminal number. In the ideal circumstance, the RC region corresponding to the translated 10-digit NANP number is the same as the RC region corresponding to the calling terminal number. However, the two RC regions being the same or different shall not be constructed as limitations to the scope of the present invention. Further, the 10-digit NANP number is configured as a parameter into the Naming Authority Pointer (NAPTR) record corresponding to the calling terminal number, and therefore, the 10-digit NANP number is returned along with the ENUM response to the call control server, and the special service is implemented in the area where the calling user is located, or in a nearby area.

0082Improved solution 2: Planned domain names of the calling terminal number and the called terminal number are generated to judge the call type.

0083The detailed steps of this solution are as follows:

0084Generate planned domain names of the calling terminal number and the called terminal number according to the planned area names corresponding to the plan information of the calling terminal number and the called terminal number.

0085Check whether a Domain Name System (DNS) that stores a set of local call domain names includes the planned domain names of the calling terminal number and the called terminal number.

0086If the DNS includes the planned domain names, determine that the calling terminal number and the called terminal number are located in the same local calling area, and receive the local call type parameter generated by the DNS; if the DNS does not include the planned domain names, determine that the calling terminal number and the called terminal number are located in different local calling areas.

0087Still taking the North America communication control network as an example, the improved solution is as follows:

0088First, in a DNS, neighboring RCs are stored in the form of related domain names. For example, if RC<b>1</b> is adjacent to RC<b>2</b> and RC<b>3</b>, the DNS stores domain names “RC<b>1</b>.RC<b>2</b>” and “RC<b>1</b>.RC<b>3</b>”, and other neighboring RCs are processed in the same way.

0089The basis for the call control server to judge the call type of a call is not only the LATA and RC information published by the LERG but also the Local Calling Area information, which helps the call control server to judge whether the call is of the Local type or Local Toll type. However, the Local Calling Area information is not published along with the LERG data. Based on the technical conception herein, the call control server may make the RC names of the calling user and the called user into a domain name such as “RC<b>1</b>.RC<b>2</b>”, and query for the NAPTR record in the DNS that stores such related domain names.

0090If no record is found, it indicates that the RC of the calling user and the RC of the called user are in different local calling areas, namely, the call type of the call between the calling user and the called user is not “Local”; if the corresponding record is found, it indicates that the RC of the calling user and the RC of the called user are in the same local calling area, namely, the call type of the call between the calling user and the called user is “Local”.

0091After completion of the query, the DNS returns information to the call control server, where the information carries a parameter indicating whether the call type of the call between the calling user and the called user is “Local” or “Local Toll”.

0092It should be further noted that, the related domain name solution put forward in improved solution 2 is only a preferred embodiment of the present invention. Other methods with the same technical effect, for example, SRV records, are also covered in the protection scope of the present invention.

0093The technical solution in this embodiment brings these benefits: The number information storage server stores and manages the number plan information, and each call control server can query for the number plan information. Therefore, the number plan information is stored together and managed uniformly, which reduces the maintenance cost and saves the storage space and hardware resources.

0094Corresponding to the method above, a call control network is provided in the second embodiment. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the call control network includes a number information storage server <b>1</b> and a call control server <b>2</b>.

0095The number information storage server <b>1</b> is configured to: store plan information and/or plan-related information of a number, and further configured to update the plan information of the number according to routing update information. The number information storage server <b>1</b> includes:

0096a storing module <b>11</b>, configured to store plan information and/or plan-related information of a number;

0097a receiving module <b>12</b>, configured to receive a message from the call control server <b>2</b>, where the message is for querying for plan information of a calling terminal number and/or a called terminal number;

0098a querying module <b>13</b>, configured to: query the storing module <b>11</b> for the plan information of the calling terminal number and/or the called terminal number according to the message received by the receiving module <b>12</b>; and/or query the storing module <b>11</b> for plan-related information according to the plan information of the calling terminal number and/or the called terminal number; and

0099a sending module <b>14</b>, configured to: send the plan information of the calling terminal number and/or the called terminal number to the call control server <b>2</b>, and/or send the plan-related information to the call control server <b>2</b>, where the plan information and the plan-related information are obtained by the querying module <b>13</b>.

0100Further, the number information storage server <b>1</b> includes:

0101an updating module <b>15</b>, configured to update the number plan information stored in the storing module <b>11</b> according to a routing update guide file.

0102Taking the North America communication control network as an example, the routing update guide file is the latest data published by a special organization in North America periodically in the form of LERG text files, which are generally LERG6.DAT and LERGINS.DAT files. Other routing update guide files with the same technical effect are also covered in the protection scope of the present invention.

0103The querying module <b>13</b> in the number information storage server may query the storing module <b>11</b> for the plan information of the calling terminal number and/or called terminal number. After obtaining the plan information of the calling terminal number and/or called terminal number, the querying module <b>13</b> in the number information storage server may further query the storing module <b>11</b> for the plan-related information according to the plan information, and then the sending module sends the obtained information to the call control server <b>2</b>.

0104Further, the number information storage server <b>1</b> may include a judging module <b>16</b>, which is configured to judge the call type according to the plan-related information, whereupon the call type of the call service corresponding to the call request can be carried directly in the query result which is returned subsequently. The number information storage server <b>1</b> may further include:

0105a judging module <b>16</b>, configured to judge the call type of the call service corresponding to the call request according to the plan information of the calling terminal number and/or called terminal number and plan-related information obtained by the querying module <b>13</b>, whereupon the call type of the call service corresponding to the call request can be carried directly in the query result which is returned subsequently; and

0106a generating module <b>17</b>, configured to generate a plan parameter of the called terminal number according to the plan information of the calling terminal number if the called terminal number is a preset service number, whereupon the sending module <b>14</b> sends the plan parameter of the called terminal number to the call control server <b>2</b>.

0107The number information storage server <b>1</b> may be a single number information storage server, or a number information storage server pool including more than one number information storage server.

0108The call control server <b>2</b> is configured to: query the number information storage server <b>1</b> for plan information of a calling terminal number and/or a called terminal number of a call service, and judge a call type of the call service according to the plan information and/or plan-related information. The call control server <b>2</b> includes:

0109a receiving module <b>21</b>, configured to receive a call request from a calling terminal, where the call request carries a calling terminal number and a called terminal number;

0110a first querying module <b>22</b>, configured to query a number information storage server <b>2</b> for plan information of the calling terminal number and/or the called terminal number in the call request received by the receiving module <b>21</b>, and/or plan-related information; and

0111a judging module <b>23</b>, configured to judge a call type of a call service corresponding to the call request according to the plan-related information and/or the plan information of the calling terminal number and/or the called terminal number, where the plan information and/or plan-related information is obtained by the first querying module <b>22</b>.

0112The call control server <b>2</b> further includes:

0113a storing module <b>24</b>, configured to: store plan information of the calling terminal number at the time of registering the calling terminal; or store the plan information of the calling terminal number and/or the called terminal number, which is obtained by the first querying module <b>22</b>.

0114Accordingly, the first querying module <b>22</b> is further configured to query the storing module <b>24</b> for the plan information of the calling terminal number and/or the called terminal number.

0115The call control server <b>2</b> further includes:

0116a generating module <b>25</b>, configured to generate planned domain names of the calling terminal number and the called terminal number according to the planned area names corresponding to the plan information of the calling terminal number and the called terminal number, where the plan information is obtained by the first querying module <b>22</b>; and

0117a second querying module <b>26</b>, configured to check whether a DNS that stores a set of local call domain names includes the planned domain names of the calling terminal number and the called terminal number, where the planned domain names are generated by the generating module <b>25</b>.

0118In a specific application scenario, the call control server <b>2</b> may be a Call Session Control Function (CSCF) entity and/or an Application Server (AS) in an IP Multimedia Subsystem (IMS), or a call control server in a softswitch network. Such variations are also covered in the protection scope of the present invention.

0119The foregoing modules may be distributed in one apparatus or more apparatuses. The foregoing modules may be combined into one module, or split into multiple submodules.

0120The technical solution in this embodiment brings these benefits: The number information storage server stores and manages the number plan information, and each call control server can query for the number plan information. Therefore, the number plan information is stored together and managed uniformly, which reduces the maintenance cost and saves the storage space and hardware resources.

0121The following embodiments expound the technical solution under the present invention, taking the North America communication control network as an example. The embodiments given herein are only preferred embodiments of the present invention, and other networks compliant with the requirements of the implementation scenario of this technical solution are also covered in the protection scope of the present invention. In the specific implementation scenarios, the names given herein shall not be constructed as limitations to the protection scope of the present invention.

0122In the case of the North America communication control network, the technical solution under the present invention uses an ENUM server to store and manage the number plan information (LERG6 data), and provides a standard ENUM query interface for each call control server to perform centralized storage and uniform management for the number plan information. The number plan information includes LATA information and RC information. The relations between the LATA and the RC are as shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0123Each call control server may query the ENUM server for the number plan information through a standard ENUM NAPTR. The calling terminal number and the called terminal number are input to the ENUM server through a standard ENUM query interface. The call control server queries for the matching NAPTR records on the ENUM server, and returns the number plan information such as LATA and RC corresponding to the number.

0124In the North America communication control network, the first six digits of the number, namely, NPA-NXX, can uniquely determine the LATA and RC information of the number. This embodiment takes two numbers as examples, whose first six digits are 612-201 and 207-698 respectively.

0125Two NAPTR records of 612-201 and 207-698 on the ENUM server are: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0126">*.1.0.2.2.1.6 IN NA PTR 100 10 “u” “sip+E2U” “!̂(.*)$!sip:\\1;</li><li id="ul0002-0002" num="0127">napn_lata=628;napn_rc=TWINCITIES!”.</li><li id="ul0002-0003" num="0128">*.8.9.6.7.0.2 IN NA PTR 100 10 “u” “sip+E2U” “!̂(.*)$!sip:\\1;</li><li id="ul0002-0004" num="0129">napn_lata=120;napn_rc=BERWICK!”.</li></ul></li></ul>

0130As shown above, the number with the initial “612-201” is mapped to a Sip URI through the NAPTR record. The Sip URI includes the parameters that carry LATA and RC information. The LATA information is a 3-digit identifier “628”; and the RC information is an identification character composed of up to 10 digits. The RC information of the number with the initial “612-201” is composed up of 10 digits, namely, TWINCITIES.

0131In this way, when the call control server queries for the ENUM by using the 612-201-XXXX number, such parameters serve as the plan information of the number, and are returned along with the query response to the call control server.

0132Likewise, the number with the initial “207-698” is mapped to a Sip URI through the NAPTR record. The Sip URI includes the parameters that carry LATA and RC information. The LATA information is a 3-digit identifier “120”; and the RC information is an identification character composed of up to 10 digits. The RC information of the number with the initial “207-698” is composed up of 7 digits, namely, BERWICK.

0133To avoid confusion with other ENUM query, a separate top level domain may be defined. For ease of description herein, “e164.arpa” is taken as an example of the top level domain.

0134Based on the foregoing rule settings, the third embodiment of the present invention gives a detailed process of implementing the technical solution, supposing that the calling user 612-201-1234 originates a call to the called user 207-698-4321. As shown in <figref idref="DRAWINGS">FIG. 4</figref>, the process includes the following steps:

0135Step S<b>401</b>: The calling terminal sends a call setup request that carries the calling terminal number and the called terminal number to the call control server.

0136Step S<b>402</b>: The call control server sends a query request to the ENUM server, requesting to query for the plan information of the calling terminal number.

0137That is, the call control server sends an NAPTR query message that carries the E164 number “612-201-1234” of the calling user, requesting to query for the plan information of this number.

0138In the technical solution under the present invention, the call control server queries the ENUM server through a standard ENUM interface. Therefore, at the time of sending the calling terminal number and the called terminal number to the ENUM server, the existing E164 number is translated into the DNS domain name compliant with the standard ENUM interface before the number is transmitted. For example, the E164 number “612-201-1234” is mapped to the DNS domain name “4.3.2.1.1.0.2.2.1.6.e164.arpa”, where “e164.arpa” is a top level domain designed for the ENUM server to identify the information.

0139Therefore, the details of step S<b>402</b> are: The call control server sends a query message through the standard ENUM interface. The query message carries a DNS domain name “4.3.2.1.1.0.2.2.1.6.e164.arpa”, and requests to query for the corresponding plan information.

0140The same is applicable throughout this document, and will not be repeatedly described in the subsequent embodiments.

0141Step S<b>403</b>: The ENUM server sends a query response to the call control server. The query response carries the plan information of the calling terminal number.

0142That is, the ENUM server sends an NAPTR response that carries the plan information of the calling terminal number to the call control server. The plan information includes LATA information and RC information.

0143Step S<b>404</b>: The call control server sends a query request to the ENUM server, requesting to query for the plan information of the called terminal number.

0144That is, the call control server sends a query message through the standard ENUM interface. The query message carries a DNS domain name “1.2.3.4.8. 9.6.7.0.2.e164.arpa”, and requests to query for the corresponding plan information.

0145Step S<b>405</b>: The ENUM server sends a query response to the call control server. The query response carries the plan information of the called terminal number.

0146That is, the ENUM server sends an NAPTR response that carries the plan information of the called terminal number to the call control server. The plan information includes LATA information and RC information.

0147Step S<b>402</b> and step S<b>403</b> complete the process of querying for the plan information of the calling terminal number; step S<b>404</b> and step S<b>405</b> complete the process of querying for the plan information of the called terminal number. However, the process of querying for the plan information of the calling terminal number may occur before, during or after the process of querying for the plan information of the called terminal number. The change of the sequence of such steps shall not be constructed as limitations to the protection scope of the present invention.

0148Step S<b>406</b>: The call control server judges the call type of the call service between the calling user and the called user according to the received plan information of the calling terminal number and called terminal number.

0149The judgment rules are described below:

0150As shown in <figref idref="DRAWINGS">FIG. 3</figref> that illustrates the relation between the LATA and the RC, supposing that number A in LATA<b>1</b> belongs to RC<b>1</b>, if a call is originated from this number to a number in LATA<b>2</b>, the call type of the call is InterLATA, namely, a call between different LATAs; if a call is originated from number A to a number in RC<b>6</b> in LATA<b>1</b>, because both the calling number and the called number belong to LATA<b>1</b>, the call type of the call is IntraLATA, namely, a call in the same LATA; if a call is originated from number A to a number in RC<b>1</b>, because the calling number and the called number belong to the same RC, the call type of the call is Local.

0151Step S<b>407</b>: The call control server sends a call setup message to the called user to set up a call service between the calling user and the called user.

0152In this embodiment, the call control server obtains the LATA and RC information of the calling number and the called number through two attempts of NAPTR query, and determines the call type of the call through the local judgment logic. In this way, the call type is determined without the need of storing masses of data locally.

0153Specifically, the technical solution in the third embodiment of the present invention may be implemented in an IMS network, where the call control server is a CSCF. The CSCF queries the ENUM server for the plan information of the calling terminal number and the called terminal number through a standard ENUM query interface, and determines the call type of the call service according to the obtained plan information.

0154In the IMS network, because the call control is separated from the service, the AS needs to obtain LATA and RC information of the user through the ENUM query interface in certain scenarios.

0155<figref idref="DRAWINGS">FIG. 5</figref> shows a schematic diagram of a structure of a call control network in an IMS network based on the technical solution in this embodiment.

0156As shown in <figref idref="DRAWINGS">FIG. 5</figref>, the number plan information is stored in a centralized way in this networking architecture so that the data can be maintained and updated conveniently; moreover, a standard ENUM interface is applied between the CSCF/AS and the ENUM, without involving any extension, and therefore, the modification of the existing network is minimized, and the cost is controlled efficiently.

0157Because the data is stored in a centralized way in this networking architecture, to provide higher reliability, the ENUM server may be deployed in the form of a resource pool to implement load sharing and disaster recovery.

0158The fourth embodiment deals with the method for a CSCF to judge the call type in an IMS network. <figref idref="DRAWINGS">FIG. 6</figref> shows a schematic diagram of a flowchart of a method for querying, by a CSCF, an ENUM server in an IMS network.

0159In this embodiment, it is still assumed that the calling user 612-201-1234 originates a call to the called user 207-698-4321. The method includes the following steps:

0160Step S<b>601</b>: The terminal sends a call setup request that carries the calling terminal number and the called terminal number to a Proxy CSCF (P-CSCF).

0161Step S<b>602</b>: The P-CSCF forwards the call setup request that carries the calling terminal number and the called terminal number to a Serving CSCF (S-CSCF).

0162Step S<b>603</b>: The S-CSCF sends a query request to an ENUM server, requesting to query for the plan information of the calling terminal number.

0163That is, the S-CSCF sends a query message through a standard ENUM interface. The query message carries a DNS domain name “4.3.2.1.1.0.2.2.1.6. e164.arpa”, and requests to query for the corresponding plan information.

0164Step S<b>604</b>: The ENUM server sends a query response that carries the plan information of the calling terminal number to the S-CSCF.

0165That is, the ENUM server sends an NAPTR response that carries the plan information of the calling terminal number to the S-CSCF. The plan information includes LATA information and RC information.

0166Step S<b>605</b>: The S-CSCF sends a query request to an ENUM server, requesting to query for the plan information of the called terminal number.

0167That is, the S-CSCF sends a query message through a standard ENUM interface. The query message carries a DNS domain name “1.2.3.4.8.9.6.7.0.2. e164.arpa”, and requests to query for the corresponding plan information.

0168Step S<b>606</b>: The ENUM server sends a query response that carries the plan information of the called terminal number to the S-CSCF.

0169That is, the ENUM server sends an NAPTR response that carries the plan information of the called terminal number to the S-CSCF. The plan information includes LATA information and RC information.

0170Step S<b>607</b>: The S-CSCF judges the call type of the call service between the calling user and the called user according to the received plan information of the calling terminal number and called terminal number.

0171Step S<b>608</b>: The S-CSCF sends a call setup message to the AS to set up the call service between the calling user and the called user.

0172In this embodiment, the call control server obtains the LATA and RC information of the calling number and the called number through two attempts of NAPTR query, and determines the call type of the call through the local judgment logic. In this way, the call type is determined without the need of storing masses of data locally.

0173Specifically, in this call process, the calling CSCF needs to query the ENUM server for the calling terminal number and the called terminal number respectively to obtain the LATA and RC information of the calling terminal number and the called terminal number, and then determine the call type of this call through the local judgment logic.

0174In certain services, the judgment and the subsequent service cannot go on unless the call type is known. For example, the service needs to restrict the calls of a certain call type. In this case, the CSCF needs to send the determined call type to the AS in a certain way before triggering the operation on the AS. Specifically, the call type may be carried in a parameter of a certain format in a Session Initiation Protocol (SIP) message. When the service of the AS involves modification of the calling terminal number or called terminal number, after the operation is triggered on the AS and delivered to the CSCF, the CSCF still needs to judge the call type again.

0175Due to the impact of the service, an alternative practice is: The AS judges the call type instead. In this case, the ENUM query occurs on the AS, which is detailed in the fifth embodiment. As shown in <figref idref="DRAWINGS">FIG. 7</figref>, the fifth embodiment includes the following steps:

0176Step S<b>701</b>: The terminal sends a call setup request that carries the calling terminal number and the called terminal number to a P-CSCF.

0177Step S<b>702</b>: The P-CSCF forwards the call setup request that carries the calling terminal number and the called terminal number to an S-CSCF.

0178Step S<b>703</b>: The S-CSCF forwards the call setup request that carries the calling terminal number and the called terminal number to an AS.

0179Step S<b>704</b>: The AS sends a query request to an ENUM server, requesting to query for the plan information of the calling terminal number.

0180That is, the AS sends a query message through a standard ENUM interface. The query message carries a DNS domain name “4.3.2.1.1.0.2.2.1.6. e164.arpa”, and requests to query for the corresponding plan information.

0181Step S<b>705</b>: The ENUM server sends a query response that carries the plan information of the calling terminal number to the AS.

0182That is, the ENUM server sends an NAPTR response that carries the plan information of the calling terminal number to the AS. The plan information includes LATA information and RC information.

0183Step S<b>706</b>: The AS sends a query request to an ENUM server, requesting to query for the plan information of the called terminal number.

0184That is, the AS sends a query message through a standard ENUM interface. The query message carries a DNS domain name “1.2.3.4.8.9.6.7.0.2. e164.arpa”, and requests to query for the corresponding plan information.

0185Step S<b>707</b>: The ENUM server sends a query response that carries the plan information of the called terminal number to the AS.

0186That is, the ENUM server sends an NAPTR response that carries the plan information of the called terminal number to the AS. The plan information includes LATA information and RC information.

0187Step S<b>708</b>: The AS judges a call type of a call service between the calling user and the called user according to the received plan information of the calling terminal number and called terminal number.

0188Step S<b>709</b>: The AS sends the call setup message to the S-CSCF. The S-CSCF performs subsequent operations to set up the call service between the calling user and the called user.

0189Through the foregoing technical solution, the AS needs to query the ENUM server as long as the service imposes an impact on the call type.

0190Further, in certain application scenarios, both the CSCF and the AS need to query the ENUM server and judge the call type to ensure data accuracy. In this case, the technical solution is similar, and is not further described here. Such variations of the technical solution are also covered in the protection scope of the present invention.

0191In the sixth embodiment of the present invention, the plan information is stored in a number information storage server such as a Home Subscriber Server (HSS) or a Home Location Register (HLR) in a centralized way, and a call control server (S-CSCF/I-CSCF/AS) or a number information storage server (HSS/HLR) judges the call type. The following describes the process of judging the call type with reference to <figref idref="DRAWINGS">FIG. 8</figref>.

0192Step <b>801</b>: The S-CSCF receives a user registration message, and sends a Server-Assignment-Request (SAR) to download the user subscription data.

0193It should be noted that, if the user is not registered, or if no plan information of the user exists in the locally registered user data, the S-CSCF may use the NPA-NXX of the calling number to query the HSS first and obtain the plan information of the calling user.

0194Step <b>802</b>: After receiving the user subscription data from the S-CSCF, the HSS downloads the plan information (RC, LATA) of the user from a Server-Assignment-Answer (SAA) in a group AVP format.

0195Step <b>803</b>: After receiving the plan information from the HSS, the S-CSCF saves the plan information locally.

0196Step <b>804</b>: The S-CSCF returns a <b>200</b> response.

0197Step <b>805</b>: After receiving an Invite request, the S-CSCF extracts the called number from the Request-URI and regulates the number.

0198Step <b>806</b>: The S-CSCF finds that the Invite request carries no Call Type information, and uses the NPA-NXX in the calling number and the NPA-NXX in the called number to query the local configuration first. If the call type can be obtained in the local configuration, it is not necessary to query for the plan information of the called number; if the call type cannot be obtained in the local configuration, the S-CSCF uses the NPA-NXX in the called number to construct a Public Service Identities (PSI) of the TEL format, and then sends an SAR to the HSS to obtain the plan information.

0199Step <b>807</b>: After receiving the SAR, the HSS performs precise matching to obtain plan information of the PSI according to the PSI, and returns the plan information to the S-CSCF in a group AVP format.

0200Step <b>808</b>: The S-CSCF judges the call type according to the plan information (RC and LATA data) of the calling number and called number and the plan-related information (Local RC) stored locally, and obtains the call type and carries it in a “trunk group” parameter in the request. The S-CSCF saves the NPA-NXX in the calling number, the NPA-NXX in the called number, and the corresponding call type locally.

0201After completion of this call, if the user dials the called number again, the process proceeds to the following steps:

0202Step <b>809</b>: After receiving an initial Invite request, the S-CSCF extracts the NPA-NXX from the calling number and the called number, and queries the local configuration to obtain the call type.

0203Step <b>810</b>: The S-CSCF sends a request that carries the call type.

0204In this case, because the S-CSCF has stored the call type corresponding to the call between the specific calling number and called number, the call type is obtained locally for this initial call request, without the need of querying the HSS.

0205To prevent seldom used redundant data from occupying the HSS/HLR memory space, the stored plan information complies with a certain storage period and aging mechanism. For example, the storage period may be the maximum registration duration supported by the system.

0206<figref idref="DRAWINGS">FIG. 9</figref> shows a process for judging a call type according to the seventh embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 9</figref>, the process of judging the call type includes the following steps:

0207Step <b>901</b>: After receiving an Invite request, an Interrogating CSCF (I-CSCF) extracts the called number from the Request-URI and regulates the number.

0208Step <b>902</b>: The I-CSCF finds that the request carries no call type information, and uses the NPA-NXX in the calling number and the NPA-NXX in the called number to query the local configuration first. If no call type is obtained from the local configuration, the I-CSCF uses the NPA-NXX in the calling number to construct a PSI of the TEL format, and sends a Location-Info-Request (LIR) to download the user data.

0209Step <b>903</b>: After receiving the LIR, the HSS performs precise matching to obtain plan information of the PSI according to the PSI, and returns a Location-Info-Answer (LIA) to the I-CSCF in a group AVP format.

0210Step <b>904</b>: After receiving the LIA, the I-CSCF obtains the plan information of the calling number and stores the information locally, and uses the NPA and NXX in the called number to construct a PSI of the TEL format, and sends an LIR to download the user data.

0211Step <b>905</b>: After receiving the LIR, according to the PSI the HSS performs precise matching to obtain plan information corresponding to the PSI, and returns a LIA to the I-CSCF in a group AVP format.

0212Step <b>906</b>: After receiving the LIA, the I-CSCF obtains the plan information of the calling number and stores it locally. The I-CSCF judges the call type according to the obtained plan information (RC and LATA data) of the calling number and called number and the plan-related information (Local RC), and obtains the call type and carries it in the request. The I-CSCF saves the NPA-NXX in the calling number, the NPA-NXX in the called number, and the corresponding call type locally.

0213Step <b>907</b>: After receiving an initial Invite request, the I-CSCF extracts the NPA-NXX from the calling number and the called number, and queries the local configuration to obtain the call type.

0214Step <b>908</b>: The I-CSCF sends a request that carries the call type.

0215In the foregoing embodiment, the plan information of the calling number and the plan information of the called number may be downloaded from the HSS together.

0216The scenario where an AS stores the location-related information (Local RC) locally is similar to the sixth embodiment and the seventh embodiment described above. The HSS/HLR stores the LATA data and RC data, and the AS uses a PSI to download LATA and RC data through an SH interface. If an AS that supports the third-party registration and provides services is registered with a third party, the plan information (RC, LATA) of the user is downloaded from the HSS/HLR through an SH interface according to the IMS Public User Identity (IMPU). The subsequent process is similar to the process that the S-CSCF or I-CSCF obtains the call type.

0217In the process of judging the call type in the sixth and seventh embodiments, the Local RC data is stored locally; the S-CSCF/I-CSCF judges the call type of the call according to the calling/called number plan information (RC, LATA) obtained from the HSS and the local RC data stored locally. In another embodiment, the LATA data, the RC data, and the Local RC data are stored in an HSS, and an I-CSCF/S-CSCF/AS judges the call type, as detailed below.

0218<figref idref="DRAWINGS">FIG. 10</figref> shows how an I-CSCF/S-CSCF/AS judges a call type according to the eighth embodiment of the present invention. The process includes the following steps:

0219Steps <b>1001</b>-<b>1005</b>: After receiving an Invite request, the plan information of the calling number and the called number is obtained through an interaction with the HSS. The process is similar to the previous embodiment, and is not repeatedly described.

0220Step <b>1006</b>: The call control server (I-CSCF/S-CSCF) or AS sends a User-Relation-Request (URR) to the HSS according to the obtained calling/called number plan information. The request carries a relation type flag (such as a location relation).

0221More specifically, the plan-related information (Local RC) of the user is stored on the HSS/HLR. After receiving a request for querying for the user relation information from the call control server (I-CSCF/S-CSCF) or AS, the HSS queries for the user relation information (Local RC).

0222Step <b>1007</b>: After receiving a location relation response from the HSS, the call control server (I-CSCF/S-CSCF) or AS judges the call type of the call according to the relation result, namely, plan-related information.

0223If the relation result is empty or null, it is not necessary to change the local call type; if the relation result shows existence of a relation, the local call type needs to be replaced with the specific relation information.

0224Step <b>1008</b>: The call control server (I-CSCF/S-CSCF) or AS sends a request that carries the call type.

0225This embodiment differs from the sixth embodiment and the seventh embodiment in that: All plan information and plan-related information are stored on the HSS/HLR in a centralized way, thus reducing the data redundancy and improving the data reliability; and the call type is still judged by the call control server (I-CSCF/S-CSCF) or AS, and the HSS/HLR only stores and manages data, not involving service logics.

0226In another embodiment of the present invention, the plan information and the Local RC information are stored on the HSS/HLR, and the HSS/HLR judges the call type. In this case, the call type of a call is obtained through only one interaction, thus improving the efficiency of the whole call control network. This implementation mode is described below with reference to the ninth embodiment and <figref idref="DRAWINGS">FIG. 11</figref>.

0227As shown in <figref idref="DRAWINGS">FIG. 11</figref>, the HSS/HLR judges the call type in the following way:

0228Step <b>1101</b>: After receiving an initial Invite request, the I-CSCF/S-CSCF/AS finds that no call type is carried in the request, uses NPA NXX in the calling number and the called number to construct a calling/called PSI in a User-Relation-Request (URR), and inputs user identifier information as a relation management flag.

0229Step <b>1102</b>: The I-CSCF/S-CSCF/AS sends the URR to the HSS.

0230Step <b>1103</b>: The HSS queries the corresponding subscription data according to the calling/called PSI to obtain the plan information of the calling number and the called number and the plan-related information; judges the call type according to the plan information of the calling number and the called number and the plan-related information, and obtains the call type information. The HSS inputs the call type information into the specific relation information in a User-Relation-Answer (URA), and returns the response to the I-CSCF/S-CSCF/AS.

0231Step <b>1104</b>: Because the relation result indicates existence of a relation, the I-CSCF/S-CSCF/AS extracts the call type from the detailed relation information, and carries it in an Invite request to be sent.

0232In the technical solution in this embodiment, an HSS/HLR or an ENUM server in the IMS/ Next Generation Network (NGN) architecture stores the data in a centralized way, namely, stores LATA data, RC data, and/or Local RC data together so that the user data is managed uniformly; and a call control server or an HSS/HLR judges the call type according to the LATA and RC, and/or Local RC, thus saving the memory of the call control device/switch massively, reducing the interactions in the process of judging the call type, and improving the efficiency and reliability of data storage.

0233Although this embodiment describes the technical solution implemented in an IMS network, the technical solution may be implemented in a softswitch network as well. That is, the softswitch call control server queries the ENUM server, or upgraded HLR, or HSS/HLR, and judges the call type of the call according to the query result. The query process is the similar to that described in the preceding embodiments, and is not further described here.

0234The technical solution in this embodiment brings these benefits: The number information storage server such as the ENUM server, or HSS/HLR stores and manages the number plan information, and each call control server can query for the number plan information. Therefore, the number plan information is stored together and managed uniformly, which reduces the maintenance cost and saves the storage space and hardware resources.

0235Moreover, a method, device, and system for judging a call type by applying the number information storage server are provided herein to facilitate the terminal to judge the call type.

0236After reading the foregoing embodiments, those skilled in the art are clearly aware that the present invention may be implemented through hardware, or through software in addition to a necessary universal hardware platform. The technical solution under the present invention may be embodied as a software product. The software product may be stored in a computer-readable storage medium (such as a CD-ROM, a USB flash disk, or a mobile hard disk), and may include several instructions that enable a computer device (such as a personal computer, a server, or a network device) to perform the methods specified in any embodiment of the present invention.

0237The above descriptions are merely some exemplary embodiments of the present invention, but not intended to limit the scope of the present invention. Any modifications, variations or replacement that can be easily derived by those skilled in the art should fall within the scope of the present invention. Therefore, the scope of the present invention is subject to the appended claims.