GB2592629A

GB2592629A - Processing service requests and processing DNS queries in telephony networks

Info

Publication number: GB2592629A
Application number: GB2003140.7A
Authority: GB
Inventors: Amin Al-Damluji Salem
Original assignee: Metaswitch Networks Ltd
Current assignee: Metaswitch Networks Ltd
Priority date: 2020-03-04
Filing date: 2020-03-04
Publication date: 2021-09-08
Also published as: WO2021178599A1; GB202003140D0

Abstract

A service request for a telephony service (e.g. a telephone call, or SMS/MMS messaging) provided by a network 130 is received by a DNS client 160. The client transmits a DNS query to a private DNS server 170, the query comprising data derived from the service request, e.g. data derived from a calling and/or called telephone number. The DNS query may be an ENUM (E.164 number to URI mapping) based query. A DNS response, e.g. ENUM response, is received indicative of a handling action to be performed in relation to the service request. A telephony service handling outcome, e.g. reject or accept the service request, is determined based at least in part on the handling action indicated by the DNS response, and the service request is processed accordingly. As a result, unwanted calls can be rejected. The DNS server may apply one or more rules to information within the query and respond with a DNS response code (RCODE) indicating the handling action. Multiple DNS/ENUM servers may be queried and the service handling outcome based on the multiple responses. The DNS query may use an extension mechanism for DNS (EDNS) to indicate additional information associated with the service request.

Description

PROCESSING SERVICE REQUESTS AND PROCESSING DNS QUERIES IN 1ELEPHONY NETWORKS

Technical Field

The present disclosure relates to processing service requests and to processing Domain Name System (DNS) queries in telephony networks.

Background

Telephony network operators (also known as "network operators") wish to be able to reject malicious, spam, and otherwise unwanted calls within their networks.

This improves the user experience of legitimate customers and spares the resources otherwise devoted to such calls. Network operators may wish to implement rules that determine whether a call is unwanted. In practice, network operators may wish to implement upwards of 20,000 such rules, each of which may be complex. Additionally, in practice, network operators might wish to change the rules frequently, for example every minute.

Such rules could, in principle, be built into existing network components in the network operator's network. For example, such rules could be built into an existing network component on the edge of the network to reject unwanted calls at the first opportunity. Examples of such network components include, but are not limited to, Session Border Controllers (SBCs) and Interconnect Border Control Functions (IBCFs). However, this may not be effective in practice because of the factors outlined above relating to the extent and complexity of the rules.

Alternatively, network operators could refactor their networks to use existing Session Initiation Protocol (SIP) components to implement such rules. For example, following processing by an IBCF, all calls could be routed to an SBC whose only task is to implement these blocking rules. However, this is also unlikely to be effective in practice. SIP is a heavyweight, stateful protocol involving significant amounts of information and state that are necessarily irrelevant to the determination of whether service should be provided to a call.

Summary

According to first embodiments, there is provided a method of processing a service request in a telephony network, the method comprising: receiving a service request for a telephony service; transmitting a DNS query in response to the receiving of the service request, the DNS query comprising data derived from the service request; receiving a DNS response in response to the transmitting of the DNS query, the DNS response being indicative of a telephony service handling action to be performed in relation to the service request; determining a telephony service handling outcome based at least in part on the telephony service handling action indicated by the DNS response; and processing the service request in accordance with the determined telephony service handling outcome.

According to second embodiments, there is provided a method of processing a DNS query in a telephony network, the method comprising: receiving a DNS query, the DNS query comprising data derived from a service request for a telephony service; determining a telephony service handling action to be performed in relation to the service request based at least in part on the data derived from a service request for a telephony service; and transmitting a DNS response in response to the receiving of the DNS query, the DNS response being indicative of the telephony service handling action to be performed in relation to the service request.

According to third embodiments, there is provided a device configured to perform a method according to the first or second embodiments.

According to fourth embodiments, there is provided a computer program arranged, when executed, to perform a method according to the first or second embodiments.

Further features and advantages will become apparent from the following description, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 shows a schematic block diagram representing an example of a telephony system; and Figure 2 shows a sequence diagram representing an example of a method of processing a service request.

Detailed Description

Referring to Figure 1, there is shown an example of a telephony system 100 In this example, the telephony system 100 comprises source and destination telephony devices 110, 120. In this example, the source and destination telephony devices 110, 120 have example telephone numbers "12345" and "54321" respectively. In this example, the telephony system 100 comprises a telephony network 130 associated with a network operator. The telephony network may be an IP Multimedia Subsystem (IMS) network, a SIP network, etc. In this example, the telephony network 130 comprises first and second network devices 140, 150.

In this example, the first network device 140 is a SIP device comprising SBC functionality. In this example, the first network device 140 comprises DNS client 160 functionality. In this example, the DNS client 160 has E.164 Number to URI Mapping (ENUM) client functionality. ENUM is a DNS-based system, defined in RFC 6116, which is conventionally used for routing and looking up services associated with a destination telephone number. Example techniques described herein may be readily implemented on a variety of existing networking devices, such as routing devices, using existing ENUM capabilities of such devices. As such, in some examples, the first network device 140 comprises routing functionality.

In this example, the second network device 150 comprises Telephony Application Server (TAS) functionality However, the second network device 150 can comprise different functionality in other examples. ki this example, the second network device 150 comprises DNS server 170 functionality. As such, in this example, the DNS server 170 is within the telephony network 130. The DNS server 170 may be considered to be a private DNS server, under the control of the network operator associated with the telephony network 130. This differs from a public DNS server, which would be outside the telephony network 130 and would not be under the control of the network operator. In this example, the second network device 150 has an extension in the form of a server-side DNS plugin to provide the DNS server 170 functionality. In this specific example, the server-side DNS plugin comprises a server-side ENUM plugin.

In this example, an interface 180 between the DNS client 160 and the DNS server 170 is encrypted. The interface 180 may use DNS Security Extension (DNSSEC), DNSCurve, or another encryption methodology.

The devices 110, 120, 140, 150 shown in Figure 1 may comprise one or more processors and one or more memories. One or more computer programs comprising computer-readable instructions may be stored in the one or more memories. The one or more processors may be configured to execute the computer-readable instructions and perform at least some of the methods and techniques described herein as result. Some of the devices 110, 120, 140, 150 may be virtualised devices.

Referring to Figure 2, there is shown an example of a method of processing a service request. The example method may be performed in the example telephony system 100 described above with reference to Figure 1.

At item 52a, the first network device 140 receives a service request for a telephony service. In this example, the service request is received from the source telephony device 110. The requested telephony service may be for a call or any other type of telephony service. Other types of telephony service include, but are not limited to, Short Message Service (SMS) and Multimedia Message Service (NIMS). In this specific example, the service request comprises a SIP INVITE indicating that the service request is from the source telephone number "12345" associated with the source telephony device 110 and is to destination telephone number "54321" associated with the destination telephony device 120.

At item 52b, the first network device 140 transmits a DNS query in response to the receiving of the service request. The DNS query comprises data derived from the service request. The data derived from the telephony service request may comprise a source identifier (for example, based on the source telephone number "12345" in the service request), may comprise a destination identifier (for example, based on the destination telephone number "54321" in the service request), may comprise a SIP User-Agent header and/or may be indicative of a network location from which the service request is received. However, the data derived from the telephony service request may alternatively or additionally comprise other information, such as any information derived from one or more SIP message headers, any information derived from one or more SIP message bodies, and other state that may be relevant to the service request (for example, whether the request is from a registered subscriber).

In this specific example, the DNS query is an ENUM-based DNS query based on the source identifier, the destination identifier and the SIP User-Agent header. The ENLTM-based DNS query may be for a domain name based on one of the source identifier and the destination identifier. In this specific example, the ENUM-based DNS query is for a domain name based on the destination identifier. As such, in this example, the ENUM client 160 makes an ENUM lookup on the destination telephone number. In more detail, when the ENUIVI client 160 generates an ENUM-based DNS query in accordance with this example, the ENUM client 160 follows RFC 3761 and transforms the destination (or "target") E.164 number (namely, "54321") into a reverse-number dotted-format domain name for the DNS query key. The domain-name suffix is defined by local policy. In this example, the domain-name suffix is "mydomain.arpa" where "mydomain" is associated with the network operator. This allows the ENUM lookup mechanism to be for purely private use by the network operator. If, in contrast, the suffix were "e164.arpa", then the ENUM-based DNS query would be to a public ENUM server outside of the telephony network 130. In this example, the ENUM-based DNS query is for the domain name "1.2.3.4.5.mydomain.arpa". In this domain name, "1.2.3.4.5." may be considered to be a destination identifier based on the destination telephone number "54321".

In this example, the ENUM-based DNS query uses an Extension Mechanisms for DNS (EDNS) extension to indicate additional information associated with the service request. The additional information may comprise the other of the source identifier and the destination identifier (i.e, whichever of the source identifier and the destination identifier the domain name is not based on). In this specific example, that would be the source identifier. The additional information may comprise the SIP User-Agent header and/or may be indicative of the network location from which the service request is received and/or any other information as appropriate. In this specific example, the ENUM lookup uses the EDNSO extension to add additional information about the service request. In more detail, in this example, the ENUNI client 160 appends an EDNSO OPT pseudo-RR to the ENUM-based DNS query and an EDN SO Option-Code of 41. Within the Option-Data field, the ENUM client 160 includes the above-mentioned additional information as appropriate. In this specific example, the additional information comprises the source identifier in the form of the source telephone number (namely, "12345") and the User-Agent header (namely, "Android 2.7").

Although an ENUM request to the ENUM server 170 is shown at item S2b, it will be appreciated that the first network device 140 may perform another query at this, or a later, stage For example, the ENUM client 160 may perform a conventional ENUM query to obtain conventional routing information for the destination telephony device 120. This may be in the event that the service request is accepted such that telephony can be established between the source and destination telephony devices 110, 120.

At item S2c, the ENUM server 170 processes the ENUM query. In this example, such processing involves the ENUM server 170 determining a telephony service handling action to be performed in relation to the service request. The telephony service handling action may be that the service request should be rejected, may be that the service should be accepted or may be different from either such action. In more detail, in this example, the ENUM server 170 examines some or all of the information provided by the ENUM client 160 in the ENUM query and applies one or more rules configured on the ENUM server 170. In this specific example, the ENUM server 170 is configured with a rule that if the source telephone number is "12345" and the destination telephone number is "54321", then the service request should be rejected as suspected harassment. As such, in this example, the telephony service handling action is to reject the service request. In examples, the network operator may implement rules that determine that a service request is unwanted based on one or more of: a source number (for example, a known source of spam), a destination number (for example, the destination number does not exist), SIP User-Agent header (for example, indicating a call-generation device), anything derived from one or more SIP message headers, anything derived from one or more SIP message bodies, and any other state that the ENUM server 170 may hold relevant to the service request (such as whether the request is from a registered subscriber), etc. A rule may also reflect a combination of different information factors, for example calls from "12345" to -54321" are rejected because the caller appears to be harassing that callee. A rule may also use non-call information, such as time of day, day of the week, etc. This can provide a richer ability for the ENUM sewer 170 to determine whether service should be provided than with existing technology.

At item S2d, the ENUM server 170 transmits an ENUIVI response in response to the receiving of the ENUM query. In this example, a negative response to the ENUM query indicates that the requested telephony service should not be provided, while a positive response indicates that the requested telephony service should be provided. In this example, the ENUM response is indicative of the telephony service handling action to be performed in relation to the service request. In this example, DNS response code (RCODE) of the ENUM response is indicative of the telephony service handling action.

In particular, in this specific example, the ENUM response has a DNS RCODE of 9, suggesting that the EDNS server 170 is not authorized. This indicates that the telephony service handling action is to reject the service request. In this example, the ENUM response also comprises further information indicating a reason for rejection. In this specific example, the ENUM response indicates, through an OPT record, that the service request should be rejected as suspected harassment. As such, the ENUM response may indicate one or more reasons for rejection and/or a degree to which the ENUM server 170 determines the service request to be unwanted, through the DNS response code and/or through additional information in an OPT record.

Although a known protocol exists (Kaplan Draft RFC, "Routing SIP Requests with ENUM" (Internet Draft, 2012)) which has been proposed for optionally associating source URI information with ENUM lookups via an EDNS extension, the source URI is used in that proposed protocol solely to enhance routing and, again is not for use in determining, for example, whether to provide service in telephony networks. In contrast, in the present example, the DNS response does not comprise routing information.

At item S2e, the first network device 140 determines a telephony service handling outcome based at least in part on the telephony service handling action indicated by the ENUM response. In this example, the determination is additionally based on the further information, namely the indication of suspected harassment, in the OPT record. In this specific example, the telephony service handling action is to reject the service request and the determined telephony service handling outcome is the same, namely to reject the service request. In other examples, the telephony service handling outcome may be different from the telephony service handling action. For example, the first network device 140 may query multiple ENUM servers and determine the telephony service handling outcome based on potentially different telephony service handling actions indicated by the multiple ENUM servers.

At item S2f, the first network device 140 processes the service request in accordance with the determined telephony service handling outcome. In this specific example, such processing comprises the first network device 140 transmitting a rejection message, to the source telephony device 110, in response to the determined telephony service handling outcome being that the requested telephony service is not to be provided to the source telephony device 110. In this specific example, the rejection message comprises a Server Failure Response in the form of a 503 Service Unavailable message. In this example, the first network device 140 uses the additional information in the ENUM response for further processing, namely to set the 503 error code for rejection message indicative of the rejected request.

In this specific example, the service request is rejected, and no telephony service is established between the source and destination telephony devices 110, 120. In other examples, the determined telephony service handling outcome may be that the service request is accepted and telephony service is established between the source and destination telephony devices 110, 120. In such other examples, the processing at item 52f may involve the first network device 140 enabling telephony to be conducted between the source and destination telephony devices 110, 120.

Examples described above use the lightweight DNS protocol, which can avoid the need for SIP stacks. Further, such examples may be readily implemented on a variety of existing networking devices using existing DNS capabilities (for example, existing ENUM capabilities) of such devices.

As indicated above, ENUM has conventionally been used for routing and looking up services associated with a destination telephone number, and not for use in determining a telephony service handling outcome in a telephony network, such as whether or not to provide a requested telephony service. Examples described herein therefore relate to advanced use of ENUM in determining telephony service handling outcomes, such as whether or not to provide service in a telephony network.

In examples described above, rules are separated onto a separate network device, namely the second network device 150 with the ENUM server 170 functionality, which can then be queried by an existing network device, namely the first network device 140 with the ENUM client 160 functionality. This can be more effective for network operators than building the rules into existing network devices.

For example, such an arrangement better serves principles of modularity, scalability, and ease of operator use. Ease of configuration and operation can also be provided. In examples, any such queries to the separate network device use existing an existing protocol, namely a DNS-based protocol. This provides back-compatibility. Examples described herein provide an improved architecture and methodology for making and responding to such queries. Examples described herein provide an improved methodology for making requests and responses within a telephony network to determine a telephony service handling outcome, such as whether service should be provided to a call.

The above embodiments are to be understood as illustrative examples Further embodiments are envisaged.

In examples described above, a DNS lookup (such as an ENUM lookup) is performed. In addition to, or as an alternative to, using a DNS query, a network operator may query a database for whether, for example, the source telephone number is known to be a source of unwanted calls. Such databases may be accessed by a variety of mechanisms. Examples of such mechanisms include, but are not limited to, non-ENUM Application Programming Interfaces (APIs) such as HyperText Transfer Protocol (HTTP) or Structed Query Language (SQL). Several databases exist, which collect and report such telephone numbers. One known example is TrueCNAM. Such databases operate only on the source telephone number, rather than on the richer set of information described above. This may not properly fulfil the need of the network operator.

In examples described above, an ENUM lookup is made on the destination telephone number. However, the ENUM lookup may be made on the source telephone number, with the destination telephone number provided as additional information. Other combinations are envisaged.

In examples described above, a negative response to the DNS query indicates that service should not be provided, while a positive response indicates that service should be provided. Alternatively, the valences may be switched.

In examples described above, a determination is made whether a call is wanted or unwanted. However, uses other than for determination whether a call is unwanted are envisaged. For example, the techniques described above could alternatively or additionally be for other types of query, for example whether a call is a Government Emergency Telecommunications Service (GETS) call, which may need to be prioritized or given a certain service level.

Examples may be used with Message Manipulation Framework (MMF) functionality to dynamically determine the EDNS additional information. This may involve using MMF to manipulate information comprised in an incoming service request prior to transmitting a DNS query to the DNS server, for example by inspecting the incoming service request and manipulating information in the incoming service request. MMIF may be used, for example, to create new headers and extract information from other headers. For example, if a legacy network device can only pass a PAsserted-Identity header as additional information, but it is desired to pass the From and User-Agent header, MMF may be used to extract the contents of the From and User-Agent header, compress the extracted contents into a single value, and put that value in the P-Asserted-Identity header so that value gets passed as the additional information. In such an example, the contents of the From and User-Agent header are manipulated to produce manipulated information in the form of the single value in the P-Asserted-Identity header. In another example, if the ENUM server uses the network location at which the service request originated to determine the telephony service handling outcome, MMF may be used to extract the Internet Protocol (IP) address and Port from the Via header of the service request, while leaving out other, irrelevant information (such as the tags).

In examples described above, a single DNS lookup is performed. In some examples, multiple queries may be performed as part of processing a single request. For example, multiple different ENUM servers implementing different policy may be queried. As such, in some examples, a further query (e.g. a DNS query such as an ENUM query) comprising data derived from the service request is transmitted. A further response (e.g. a DNS response such as an ENUM response) is received. The further response is indicative of a further telephony service handling action to be performed in relation to the service request. The further telephony service handling action may be the same as, or may be different from, the telephony service handling action described above. The determining of the telephony service handling outcome is based further on the further telephony service handling action indicated by the further response.

In examples described above, the interface 180 between the DNS client 160 and the DNS server 170 is encrypted. In other examples, the interface 180 between the DNS client 160 and the DNS server 170 is non-encrypted.

In examples described above, it is assumed that the network operator wishes to query whether service should be provided in relation to all incoming service requests.

In other examples, such queries are performed on a subset of incoming service requests.

In some examples, the ENUM server 170 may also be in receipt of further information which helps the ENUNI server 170 determine the rules to apply. Such further information may be based on, for example, end-user feedback as to the desirability of calls from particular numbers.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

UCLAIMSI. A method of processing a service request in a telephony network, the method comprising: receiving a service request for a telephony service; transmitting a DNS query in response to the receiving of the service request, the DNS query comprising data derived from the service request; receiving a DNS response in response to the transmitting of the DNS query, the DNS response being indicative of a telephony service handling action to be performed in relation to the service request; determining a telephony service handling outcome based at least in part on the telephony service handling action indicated by the DNS response; and processing the service request in accordance with the determined telephony service handling outcome.
2. A method according to claim 1, wherein the data derived from the service request comprises a source identifier and/or a destination identifier, and wherein the DNS query is an ENIIM-based DNS query based on the source identifier and/or the destination identifier.
3 A method according to claim 2, wherein the ENUM-based DNS query is for a domain name based on one of the source identifier arid the destination identifier, and wherein the ENUM-based DNS query uses an EDNS extension to indicate additional information associated with the service request.
4. A method according to claim 3, wherein the additional information comprises the other of the source identifier and the destination identifier.
5. A method according to claim 4, wherein the domain name is based on the destination identifier and the additional information comprises the source identifier. 13'
6 A method according to any of claims 3 to 5, wherein further information related to the telephony service handling action is comprised in an OPT record, and wherein said determining is additionally based on the further information comprised in the OPT record.
7. A method according to claim 1, wherein the data derived from the service request: comprises a source identifier; comprises a destination identifier; is derived at least in part from a SIP User-Agent header; and/or is indicative of a network location from which the service request is received.
8. A method according to any of claims Ito 7, wherein the method is performed by a network element comprising routing functionality.
9. A method according to any of claims 1 to 8, wherein the DNS query is transmitted to, and the DNS response is received from, a DNS server within the telephony network
10. A method according to any of claims 1 to 9, wherein the DNS query is transmitted, and the DNS response is received, over an encrypted interface
11. A method according to any of claims 1 to 10, wherein the telephony service handling action is indicated by a DNS response code of the DNS response.
12. A method according to any of claims 1 to 11, wherein said processing comprises transmitting a rejection message in response to the determined telephony service handling outcome being that the service request is be rejected
13. A method according to claim 12, comprising setting an error code for the rejection message based on the DNS response.N
14. A method according to any of claims 1 to 13, comprising: transmitting a further query, the further query comprising data derived from the service request; and receiving a further response, the further response being indicative of a further telephony service handling action to be performed in relation to the service request, wherein said determining is based further on the further telephony service handling action indicated by the further response.
15. A method according to any of claims 1 to 14, wherein the telephony service comprises a telephone call
16. A method according to any of claims 1 to 15, wherein the telephony service comprises an SIMS.
17. A method according to any of claims 1 to 16, wherein the DNS response does not comprise routing information.
18. A method according to any of claims 1 to 17, comprising: manipulating information comprised in the received service request prior to said transmitting, wherein the data derived from the service request comprises the manipulated information.
19. A method of processing a DNS query in a telephony network, the method comprising: receiving a DNS query, the DNS query comprising data derived from a service request for a telephony service; determining a telephony service handling action to be performed in relation to the service request based at least in part on the data derived from a service request for a telephony service; and transmitting a DNS response in response to the receiving of the DNS query, the DNS response being indicative of the telephony service handling action to be performed in relation to the service request.
20. A device configured to perform a method according to any of claims 1 to 19.
21. A computer program arranged, when executed, to perform a method according to any of claims 1 to 19.