HK1148140B - A method and a node for handling an incoming request for which a user database query has failed - Google Patents

Description

Method and node for processing an incoming request for which a user database query has failed

Technical Field

The present invention relates generally to methods and apparatus for handling shared DNS domains, and more particularly to methods and apparatus for enabling a DNS domain name to be shared by two or more SIP domains.

Background

IMS (IP multimedia subsystem) is a set of standards that provides the necessary signaling, delivery, authentication and charging functions for real-time packet-based calls and services across virtually any underlying network technology. In other words, IMS is a platform suitable for efficient and fast implementation of next generation IP services in both fixed and mobile networks, which will facilitate convergence of fixed and wireless networks.

The Session Initiation Protocol (SIP) is a transport-agnostic, text-based application-layer control protocol for creating, modifying, and terminating sessions involving one or more participants, including internet calls, multimedia distribution, and multimedia conferences. SIP is widely used as a signaling protocol for voice over IP and has been accepted as a third generation partnership project (3GPP) signaling protocol for IMS.

In the 3GPP IMS Domain Name System (DNS), a domain is used to identify what SIP domain a user belongs to. In previously known applications, one DNS domain can only be represented by one SIP domain, which may be, for example, an IMS domain. Such constraints may become a problem, for example, for multinational enterprises that have outsourced their communication solutions by investing, for example, in IMS-based IP central switch/telephony Virtual Private Network (VPN) telephony. Typically for this type of situation, users are scattered around the world, where users in different geographical areas are typically managed by different operators, each operator managing a different IMS domain.

A simplified method for handling incoming requests for IMS related services at the IMS domain com 100 managed by operator a according to the prior art will now be described with reference to fig. 1. It is to be understood that although management of the IMS domain typically involves more nodes and signalling than shown in fig. 1, for reasons of clarity nodes and signalling steps not necessary for understanding the general procedure for handling incoming requests are omitted.

In a first phase 1:1, a request addressed to "user 1" (having a URI of e.g. "userldomaincom") arrives at the interrogating call session control function (I-CSCF)101 of operator a (i.e. the operator responsible for managing the IMS domain. In order to be able to route the request to "user 1," the DNS domain name of the request must be resolved correctly. This can be achieved in the next phase 1:2 by querying the user database (typically the Home Subscriber Server (HSS))102 of operator a. The HSS is the primary data storage for all IMS-related subscriber and service data for the IMS domain of operator a. The master data stored in the HSS comprises a user profile for each user registered to the IMS domain. The user profile contains user information for routing the incoming request to a serving CSCF (S-CSCF) and further to the terminating user entity. A user profile is a collection of user specific information permanently stored in the HSS, including public user identities, which may be SIP URIs, e.g. bob.

If the query to the HSS 102 results in a match, the request is routed to the operator A' S associated S-CSCF 103, as indicated in phase 1:3 a. From the S-CSCF 103, the request is forwarded to the intended terminating entity, e.g. an Application Server (AS) (not shown), which provides the requested service to the requesting party. However, if no match is found at the HSS query, the request is rejected, resulting in operator a being unable to provide the requested service to the requestor. This alternative is indicated with the last phase of the alternative 1:3 b.

Companies like Ericsson, having a URI scheme with URIs like for example "userlericsson. However, no solution for providing such features is currently known.

Disclosure of Invention

It is an object of the present invention to provide a method for allowing more than one SIP domain to utilize a DNS domain name and a device suitable for such a method. This may be achieved by letting the operator of the SIP domain know that the DNS domain name of the incoming request is a shared domain, and thus providing a mechanism for resolving the destination URI of such a request so that it can be routed accordingly rather than rejected as a result of a failed user database query performed in its own domain.

According to one aspect, a method is provided wherein a node of a SIP domain (e.g. IMS domain) is adapted to handle an incoming request for which a user database query has failed (401) (i.e. the query of the request does not result in a match). A typical node for implementing such a method is a Call Session Control Function (CSCF), e.g. an interrogating CSCF (I-CSCF).

The described scenario will typically result in a rejection of the request, since the node will not be able to find the appropriate terminating address to route it to. However, rather than rejecting the request, a procedure is proposed that determines whether the DNS domain name of the request is registered as a shared domain. Such a process may be performed by examining configuration data, which may be previously stored at or accessible to the node.

If it is determined that the DNS domain name is registered as a shared domain, the DNS domain name is resolved to a globally routable URI and the request is routed to the terminating entity. However, if the DNS domain is found not registered as a shared domain, the request will be rejected according to standard behavior.

According to one embodiment, the configuration data comprises all DNS domains managed by the operator of the SIP domain and an associated parameter indicating whether the respective DNS domain is a shared domain. Alternatively, the configuration data further comprises a post (post) for storing one or more URIs, each post indicating one or more SIP domains with which the respective shared DNS domain is shared.

According to one embodiment, configuration data comprising one or more SIP domains (i.e., the DNS domain name is shared between one or more SIP domains registered in the configuration data) may be used when resolving the DNS domain name to a globally routable URI.

According to an alternative embodiment, which may be implemented alone or in combination with the previous embodiment, no SIP domain registered in the corresponding announcement of configuration data may result in a query, e.g. a DNS query, before the DNS domain name is resolved.

According to another aspect, there is also provided a node for implementing the above mechanism. A node according to one embodiment comprises a query unit for initiating a domain checking procedure in response to a failed user database query. The domain checking unit is adapted to perform a domain checking procedure, wherein it is determined whether the requested DNS domain is registered as a shared domain. The domain checking unit is adapted to resolve the DNS domain name into a globally routable URI and route the request towards the terminating entity if the DNS domain is found to be registered as a shared domain, or to reject the request if the DNS domain is not registered as a shared domain. The domain checking process may include checking configuration data stored at or associated with the node.

According to an alternative embodiment, the domain checking unit may be adapted to resolve the requested DNS domain name into a globally routable URI on the basis of the configuration data if one or more SIP domains with which the respective DNS domain is shared are registered in the configuration data.

According to another alternative embodiment, which may be implemented separately or in combination with the previous embodiment, the domain checking unit is adapted to resolve the DNS domain name after the query has been performed if no SIP domain is registered in the configuration data.

Drawings

The invention will now be described in more detail by way of exemplary embodiments and with reference to the accompanying drawings, in which:

fig. 1 is a basic overview of a procedure for handling requests in the IMS domain according to the prior art.

Fig. 2 is a basic overview of a process for handling requests addressed to a shared DNS domain according to one embodiment.

FIG. 3 is a table showing exemplary augmented configurations, according to one embodiment.

Fig. 4 is a flow diagram illustrating a method for handling an incoming request in a SIP domain, according to one embodiment.

Fig. 5 is a flow chart illustrating an alternative way of resolving a shared IMS domain name in the method described with reference to fig. 4.

Detailed Description

Briefly, the present invention provides a mechanism for allowing more than one SIP domain to utilize DNS domain names, i.e. a mechanism is proposed which allows DNS domains to be used as shared DNS domains.

According to one embodiment, the mechanism for handling a shared DNS domain can be implemented by introducing a modified node of the SIP domain, typically an I-CSCF, which is responsible for interrogating requests arriving at the SIP domain, similar to the prior art example described earlier with reference to fig. 1. The SIP domain may be an IMS domain or any other type of network suitable for using the SIP protocol. A domain check procedure is introduced at this node of the SIP domain. This procedure will be performed in response to an unsuccessful user database query, typically a HSS query.

It is to be understood that although this illustrated embodiment is based on a modified I-CSCF, interrogating the HSS and routing the request to other CSCF nodes, the proposed mechanism will also be applicable to implementations on other entities adapted to handle the corresponding queuing and routing procedures.

According to the prior art, a user database query that does not result in a matching request will result in a rejection of the corresponding request and thus the operator cannot provide the requested service to the calling party. Instead of rejecting the request in such a case, the proposed domain checking procedure is adapted to query the extended configuration data associated with the SIP domain, wherein the already existing list of the respective SIP domain owning the DNS domain (i.e. the DNS domain managed by the SIP domain) has been extended with a parameter set for each DNS domain indicating whether the respective DNS domain is shared with another SIP domain. The node is adapted to perform a query of the incoming request, typically a DNS query procedure, when the DNS domain is a shared domain is indicated in the configuration data. The query process may involve one or more queries, which may be performed in a specific, predetermined manner, in order to enable the nodes to route requests accordingly. Alternatively, the query may be done by Diameter, Lightweight Directory Access Protocol (LDAP), or any other protocol suitable for performing this type of query.

By implementing the proposed mechanism in the SIP domain, requests addressed to the shared DNS domain will thus be routed accordingly in response to queries for additional informative configuration data, the configuration data containing data associated with DNS domains shared between different SIP domains.

A general network architecture suitable for handling DSN domain names shared by more than one SIP domain according to one embodiment will now be described in further detail with reference to fig. 2. It is to be understood that for reasons of simplicity, nodes and signaling steps not necessary for understanding the proposed mechanism are omitted. It should also be noted that the architecture shown in fig. 2 is purely logical and that the described units providing the nodes with related functionality can be implemented in different alternative ways.

Figure 2 shows how a modified SIP node 201, in this case an I-CSCF, handles a request, the node 201 being managed by operator a of the IMS domain 200 and adapted to interrogate incoming requests according to a novel domain interrogation mechanism. The I-CSCF 201 comprises a querying unit 202 adapted to perform a query of a subscriber database 203, in this case an HSS, upon receiving an incoming request. The purpose of the HSS query is to discover the appropriate serving node 204 (in this case the S-CSCF) or any other type of correspondent node responsible for delivering the request to the intended terminating entity (not shown). The terminating entity may be located in IMS domain 200 or in another domain sharing the DNS domain, e.g. IMS domain 208.

By this time the described procedure has been performed according to the well known query and routing procedures. If the relevant S-CSCF 204 is found in the user database query, the request is routed to the corresponding S-CSCF, from where it is further routed to the terminating entity (e.g., Application Server (AS) (not shown) according to standard behavior.

However, if no match is found after the query is executed, the domain check unit 205 is activated instead of rejecting the request for the next step to be executed as would normally be the case in this particular case. The domain checking unit 205 is adapted to determine whether the DNS domain of the incoming request is a shared DNS domain. This is achieved by interrogating the configuration data 206 stored at or associated with the interrogating node 201. The configuration data has been augmented with at least one new bulletin hosting parameters indicating whether the corresponding DNS domain is a shared domain or not. The configuration data may also include additional postings including local configuration information indicating one or more globally routable URIs of one or more IMS domains with which the corresponding DNS domain is shared. Based on this configuration data, requests addressed to a shared DNS domain will be routed to the relevant IMS domain, whereas requests to a DNS domain not shared with another IMS domain will be rejected by the processing unit in a conventional manner if the user database query fails.

Based on the configuration data, routing may be performed after querying or after routing to the shared IMS domain if local configuration information is accessible from the configuration data. Queries such as DNS queries typically involve querying one or more DNS servers, which may include enum DNS or enterprise specific DNS if the request includes a telephone number. In fig. 2, this query is illustrated as a DNS query performed at DNS server 207.

According to a well established procedure, the request arrives at the IMS domain 200 of operator a in a first phase 2:1, and is queried by a querying unit 202 in the next phase 2:2, where HSS203 is queried. If a match is found, i.e. if the S-CSCF associated with the respective DNS domain name is found in the HSS, the request is routed to the respective S-CSCF 204, as shown in stage 2:3 a. However, if no match is found in the HSS query, a domain checking procedure is initiated instead, as shown in alternative phase 2:3 b. The domain checking process shown in the next phase 2:4 compares the host part of the requested DNS domain name (i.e. "domain 1. com") against configuration data 206 accessible by the domain checking unit 205. If the DNS domain name is found to be shared between two or more IMS domains, the domain checking unit is adapted to resolve the DNS domain name into a globally routable URI, as indicated in a subsequent stage 2:5 a.

Initially, a parsing process adapted to interrogate the configuration data 206 is activated. The purpose of the resolution procedure is to determine whether there is any local configuration associated with the respective IMS domain, i.e. whether the configuration data 206 contains a registration of one or more globally routable URIs associated with the IMS domain with which the DNS domain is shared. If a local configuration is found, the DNS domain name is resolved so that the request can be routed to the registered IMS domain 208 managed by operator B, as indicated in phase 2: 6. If more than one IMS domain is registered in the configuration data, one of these domains (e.g., the first domain) may be selected as the next destination for routing the request. Typically, the configuration of the enquiring node 201 also contains pre-configured rules specifying how to select the domain to which to route the request. If no match is found in the selected destination domain, the enquiring node of the destination domain may be configured to route the request further to the next registered IMS domain. This procedure is typically continued until a suitable IMS domain and terminating entity is found. Alternatively, the user information of the requested destination URI may be analyzed and the result may be used to resolve the URI to the correct IMS domain already in the first location.

Although only an I-CSCF 209 is shown in the IMS domain 208 of operator B, it is to be understood that the domain 208 also comprises additional nodes, such as conventional control function nodes and servers, necessary for managing and providing IMS and/or other SIP services to end users, as for any IMS domain or any other type of SIP domain.

At the IMS domain 208, a DNS query procedure and/or any other query procedure is performed before the request can be forwarded (not shown) to the terminating destination at the IMS domain 208, all according to conventional query and routing procedures.

If no local configuration can be found in the configuration data during the parsing phase of phase 2:5a, the query process will be performed according to any known technique. The query procedure may include one or more DNS queries and/or other queries according to a configuration specified for IMS domain 200. In this example, the query performed at DNS server 207 is shown in alternate stage 2:5 b. The requested destination address is resolved into a globally routable URI based on the results from the proposed DNS query procedure. Provided with the global URI, the request can now be routed to the terminating domain 208 at phase 2: 6. At domain 208, additional routing may be performed to deliver the request to the intended terminating entity. However, if the DNS domain is not a shared domain, the request is instead denied according to standard behavior. This is shown in alternate stage 2:5 c.

A reduced table 300 showing one example of augmented configuration data according to the above-described embodiment is shown in fig. 3. The illustrated table contains three domains, "domain 1.com", "domain 2.com", and "domain 3.com", registered in the "domain" column 301. In prior art solutions such category of configuration data indicating all DNS domains of an IMS domain is already retrievable together with other configuration data for the IMS domain (e.g. information relating to e.g. authentication, service capabilities and available HSS entities of the respective IMS domain). However, the configuration data shown in fig. 3 also contains a parameter in the "shared" column 302 that indicates, for each DNS domain, whether the DNS domain is a shared domain (yes) or not (no). In addition, the table of fig. 3 may also contain an optional "shared with" column 303, in which information may be registered telling with which IMS domain or domains the corresponding DNS domain is shared. Thus, requests targeted to the DNS domain "domain 1. com" will be routed according to the routing information stored in the table, i.e. to the IMS domain "connector. com", where a conventional DNS query procedure will be performed in order to route the request to the terminating destination, whereas requests targeted to "domain 2. com" will be rejected by the enquiring node, since "domain 2. com" is not registered as a shared domain. Finally, the request with the host portion "domain 3. com" will be routed according to the information retrieved from the one or more queries.

According to another aspect, a method for processing requests addressable to a shared DNS domain will now be described with reference to the flow diagram of fig. 4. Starting at a first step 400, an interrogating SIP node requesting to reach SIP domain a (typically the IMS domain) is requested. In a next step 401, the interrogating SIP node of domain a queries the DNS domain name in the user database, wherein the query results in that no match can be found and, therefore, in that the operator cannot route the request without any further processing. After this determination, the configuration data is queried for determining whether the requested DNS domain is a shared domain. This is performed in a next step 402. If the DNS domain is found not to be a shared domain, the request is rejected according to known procedures, as shown at step 403, and the procedure then terminates at step 406. If, however, the DNS domain is a shared domain, the DNS domain name of the request is resolved into a globally routable URI in accordance with the configuration data in step 404 and the request is routed to the SIP domain in accordance with the URI, as indicated in subsequent step 405, and then the procedure of the SIP node is terminated in step 406. At the SIP domain to which the request is routed, the request is delivered to the terminating entity according to known procedures.

The parsing process indicated in step 404 of fig. 4 may be performed in different ways depending on what information can be retrieved from the configuration data.

In fig. 5, steps 404 and 405 of fig. 4 are replaced with an alternative block scheme. If it has been found that the request contains a shared DNS domain name, as shown with step 500, i.e. step 402 of fig. 4 has resulted in the alternative of "yes", it is determined whether there is a local configuration in the configuration data containing information of SIP domain B with which the DNS domain is shared. This determination is performed in the next step 501. If such information is indeed registered, the request is resolved to the appropriate address in step 502 and routed to the corresponding SIP domain B in subsequent step 505. In SIP domain B, a query procedure, typically a DNS query procedure involving one or more DNS servers, will be performed in a known manner, and the request can be routed accordingly to the terminating entity. On the other hand, if no such local configuration is found, a query procedure, e.g. a DNS query procedure, is instead performed at SIP domain a, which queries the full terminating URI of the request, as indicated by a further alternative step 503. Using the results of the query process, the terminating URI is resolved into a globally routable URI in a subsequent step 504. The URI is then used to route the request accordingly in a next step 505, after which the described resolution procedure is terminated, as indicated with step 406 of fig. 4. At the terminating domain, the request will be routed so that it reaches the terminating entity according to known procedures.

While the present invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims (20)

1. A method in a node (201) of a SIP domain (200) for handling an incoming request for which a user database query has failed (401), comprising the steps of:

-determining (402) whether the requested DNS domain name is registered as a shared domain,

-resolving (404) the DNS domain name to a globally routable URI and routing (405) the request to a terminating entity, in case the DNS domain name is registered as a shared domain, or

-rejecting (403) the request in case the DNS domain is not registered as a shared domain.

2. The method of claim 1, wherein the determining step comprises examining configuration data.

3. A method according to claim 2, wherein the configuration data comprises all DNS domains (301) managed by an operator of the SIP domain and an association parameter (302) indicating whether the respective DNS domain is a shared domain.

4. A method according to claim 3, wherein the configuration data further comprises a post (303) for storing one or more URIs, each indicating a SIP domain with which the respective DNS domain is shared.

5. A method according to claim 4, wherein if the configuration data contains one or more SIP domain names (501), this information is used in resolving (502) the DNS domain name to a globally routable URI.

6. A method according to any of claims 2-5, wherein if no SIP domain name is registered in the configuration data as a shared DNS domain, the corresponding DNS domain name is resolved (504) after the query (503) has been performed.

7. The method according to any of claims 1-5, wherein the node is a Call Session Control Function (CSCF).

8. A method as claimed in claim 7, wherein the CSCF is an interrogating CSCF (I-CSCF).

9. A method according to any of claims 1-5, wherein the SIP domain is an IMS domain.

10. The method of any of claims 1-5, wherein the query is a DNS query.

11. A node (201) of a SIP domain (200) for handling an incoming request (2: 1) for which a user database query (2: 2) has failed, comprising:

-a query unit (202) for initiating a domain checking procedure (2: 3 b) in response to the failed user database query, and

-a domain checking unit (205) for performing the domain checking procedure (2: 4), the domain checking procedure (2: 4) comprising determining whether the DNS domain of the request is registered as a shared domain, wherein the domain checking unit is adapted to resolve (2: 5a, 2:5 b) the DNS domain name to a globally routable URI and to route (2: 6) the request to a terminating entity, or to reject (2: 5 c) the request, in case the DNS domain is not registered as a shared domain.

12. The node of claim 11, wherein the domain checking procedure comprises checking configuration data stored at or associated with the node.

13. A node according to claim 12, wherein the configuration data comprises all DNS domains (301) managed by an operator of the SIP domain and an association parameter (302) indicating whether the respective DNS domain is a shared domain.

14. The node of claim 13, wherein the configuration data further comprises a post (303) for storing one or more URIs, each post indicating a SIP domain with which the respective DNS domain is shared.

15. A node according to any of claims 11-14, wherein the domain checking unit is adapted to resolve the DNS domain name into a globally routable URI on the basis of the configuration data in case one or more SIP domains with which the respective DNS domain is shared are registered in the configuration data.

16. A node according to any of claims 11-14, wherein the domain checking unit is adapted to resolve the DNS domain name after a query has been performed in case no SIP domain is registered in the configuration data.

17. A node according to any of claims 11-14, wherein the node is a Call Session Control Function (CSCF).

18. A node as claimed in claim 17, wherein the CSCF is an interrogating CSCF (I-CSCF).

19. A node according to any of claims 11-14, wherein the SIP domain is an IMS domain.

20. A node according to any of claims 11-14, wherein the query is a DNS query.