HK1132110A - Routing calls in a network - Google Patents

Description

Routing calls in a network

PRIORITY INFORMATION

This application claims priority from U.S. provisional patent application No. 60/703,812 filed on 29/2005 and U.S. provisional patent application No. 60/764,748 filed on 3/2/2006. The contents of these two provisional applications are hereby incorporated by reference in their entirety.

Background

Internet Protocol Multimedia subsystem (Internet Protocol Multimedia subsystem ims) provides mobile and fixed Multimedia services. The purpose of IMS is to provide present and future services via the internet. IMS gives network operators and service providers the ability to control and charge for each service. In addition, users are provided with the ability to perform services from their home computer/network and via their mobile devices.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, serve to explain the invention. In the drawings, there is shown in the drawings,

FIG. 1 illustrates an exemplary system in which methods and systems consistent with the principles of the invention may be implemented;

fig. 2 illustrates an exemplary configuration of the phone number mapping server of fig. 1;

FIG. 3 illustrates a portion of the system of FIG. 1;

FIGS. 4A and 4B illustrate an exemplary relationship between a telephone number mapping database associated with a peer-to-peer service provider and a telephone number mapping root server; and

fig. 5 and 6 illustrate exemplary processing by the various devices illustrated in fig. 1.

Detailed Description

The following detailed description of implementations consistent with the principles of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. The following detailed description also does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents thereof.

Implementations consistent with the principles of the invention relate to routing traffic with respect to an Internet Protocol (IP) multimedia subsystem (IMS), also referred to as an "IMS core" or "IMS platform. The IMS core may be used to route multimedia calls/data sessions from various origins to various destinations that may invoke value added services during processing and routing determinations. Calls that do not involve IMS subscriber endpoints or based on IMS applications may bypass (e.g., be routed around) the IMS core.

It should be understood that the telephony terminology used herein covers the Public Switched Telephone Network (PSTN) architecture based on the united states. Implementations consistent with the principles of the invention are not limited in this respect. For example, implementations consistent with the principles of the invention are equally applicable to other communication networks.

Exemplary System

Fig. 1 illustrates an exemplary system 100 in which methods and systems consistent with the principles of the invention may be implemented. As illustrated, the system 100 may include: a serving call session control function (S-CSCF)102, an interrogating call session control function (I-CSCF)104, a proxy call session control function (P-CSCF)106, a Home Subscriber Server (HSS)108, a predetermined location function (SLF)110, two Media Gateway (MGW) functions 112, two Media Gateway Control Functions (MGCF)114, a shared home gateway (SLG)116, a Network Gateway (NGW)118, a drop gateway control function (BGCF)120, a drop gateway control function (BIGCF)122, a Multimedia Resource Function (MRF)124, one or more application servers 132, Service Creation Environment (SCE) logic 134, a hosted Internet protocol Central office switch service (CENTREX) (HIPC)136, a unified messaging service (UM)138, a Carrier Application Service (AS)140, a Group List Management Server (GLMS)142, a presence service, a, A telephone number mapping (ENUM) server 146, an access session border controller (a-SBC)148, an internetworking session border controller (I-SBC)150, a policy engine 152, a Policy Decision Function (PDF)154, a resource management function (RM)156, a Charging Function (CF)158, a Charging Data Function (CDF)160, a Charging Gateway Function (CGF)162 and a General User Profile (GUP)164, said Multimedia Resource Function (MRF)124 may comprise a Multimedia Resource Function Controller (MRFC)126, a Multimedia Resource Function Processor (MRFP)128 and a media resource agent (MRB) 130. The component numbers illustrated in fig. 1 are provided for simplicity. In practice, a typical system may include more or fewer components than illustrated in FIG. 1.

A. Call session control component

S-CSCF102, I-CSCF104, and P-CSCF 106 may be considered call session control components in system 100. The call control component may be responsible for analyzing sessions (e.g., Session Initiation Protocol (SIP)) and application logic (e.g., business logic, service logic, operational logic, etc.) per event. The result of session control may be to route events to the appropriate components and/or to add SIP headers and values.

S-CSCF102 may be viewed as the brain of the IMS core. The term "IMS core" as used herein may refer to and include call session control components (i.e., S-CSCS 102, I-CSCF104, P-CSCF 104). The IMS core may also include HSS 108 and/or other elements associated with providing IMS-related services. Other components in system 100, such as BGCF120 and BIGCF122 may represent non-core IMS components. S-CSCF102 may perform session control and registration services for users of the IMS platform. S-CSCF102 may receive a user profile from HSS 108 and route a session requested by an IMS user (also referred to as an "IMS subscriber" or "subscriber"). In addition, S-CSCF102 may perform user authentication based on information from HSS 108.

In some implementations, S-CSCF102 may include Service Capability Interaction Manager (SCIM) and Resource Management (RM) functions. The SCIM may be responsible for coordinating the provision of one or more application services across individual services, enabling technologies and platforms to generate valuable services for IMS users. The RM may be responsible for enforcing business rules and Service Level Agreements (SLAs) by allocating appropriate resources.

I-CSCF104 may act as the primary point of contact for connecting to subscribers served by other IP networks. I-CSCF104 may be located at the edge of the IMS core. I-CSCF104 may receive the SIP message and identify the next hop (hop) of the SP message. To accomplish this, I-CSCF104 may query HSS 108 for the location (e.g., address) of the appropriate S-CSCF to which a particular SIP message is to be forwarded.

The P-CSCF 106 can act as the primary point of contact for connecting to the local IMS subscriber. As such, P-CSCF 106 may validate requests, forward the requests to a selected destination, process, and forward responses. P-CSCF 106 may generate billable events and send information related to the billable events to CF 158. In addition, P-CSCF 106 may interact with PDF 154 to grant, deny, or downgrade session requests based on platform resources and quality of service (QoS) metrics.

HSS 108 may include one or more servers that act as a central repository for user-related information. HSS 108 may contain user-related subscription information for handling multimedia sessions. Some of the information contained in HSS 108 may include information that identifies the location of a particular S-CSCF102 for a particular user. As noted above, the location of a particular S-CSCF102 may be communicated to I-CSCF104 when a query is received from a network element. HSS 108 may also include user profile information that contains service trigger points and corresponding resources (e.g., applications, media, services, etc.) for providing the services. The user profile information may be forwarded to S-CSCF102 for session control and service processing. In addition, HSS 108 may provide and receive updates directly from application server 132.

SLF 110 may include one or more databases containing service location information for subscribers. SLF 110 may receive a query from I-CSCF104 containing subscriber identification information and return information identifying HSS 108 serving the subscriber based on the subscriber identification information.

B. Gateway and gateway control function

System 100 may include various components for bridging the IMS core to external networks, such as the Public Switched Telephone Network (PSTN), the Internet (Internet), etc. These components may include MGW functionality 112, MGCF 114, SLG 116, NGW 118, BGCF120, and BIGCF122, which may perform protocol conversions and events routed to and from the IMS platform.

The MGW function 112 may connect the PSTN network and the IMS core. In one implementation, MGW function 112 may terminate bearer channels from the PSTN network and media streams from the IMS core (e.g., real-time transport protocol (RTP) streams in an IP network, or asynchronous transfer mode adaptation layer 2(AAL2)/ATM connections in an ATM backbone network), perform conversion between these terminals, and perform transcoding and signal processing. Additionally, the MGW function 112 may provide tone advertisements to Circuit Switched (CS) users. In one implementation consistent with the principles of the invention, MGW function 112 may operate under the control of MGCF 114.

MGCF 114 may be part of the gateway infrastructure that enables communication between the IMS and PSTN networks. MGCF 114 may perform protocol conversion between ISDN user part (ISUP) or basic Rate Interface (PRT) and SIP protocols before forwarding the session to the IMS platform. In a similar manner, IMS-initiated sessions directed to PSTN users may pass through MGCF 114. MGCF 140 may control media channels in MGW 112. Additionally, MGCF 114 may report account information to CF 158.

SLG 116 may include MGCF 114 and a set of associated MGW 112 entities within the same physical entity. SLG 116 may connect the IMS platform to the local switching layer of the PSTN. In one implementation, the interface between SLG 116 and the local switching network may include a non-locale associated signaling (NFAS) PRI based on digital signal 0(DS0) or digital signal 1(DS 1).

NGW 118 may include MGCF 114 and a set of associated MGW 112 entities physically located in separate physical entities. NGW 118 may connect the IMS platform to the long-range layer of the PSTN. In one implementation, the interface between MGCF 114 of NGW 118 and the long-haul network may comprise a DS0 or DS1 based signaling system 7(SS7) interface and the interface between MGW 112 of NGW 118 and the long-haul network may comprise a DS1 bearer channel.

BGCF120 may connect IMS originated calls to Circuit Switched (CS) clients (e.g., IMS users calling a telephone number in the PSTN). BGCF120 may select an appropriate network in which to connect according to routing policies or may select an appropriate MGCF to other networks.

BIGCF122 may correspond to an entry point for handling incoming calls from wholesalers, PSTN gateways (e.g., NGW 118, SLG 116, I-SBC 150), wholesale gateways (which may require prepaid authorization for non-emergency calls), other IP-based carriers (e.g., based on VoIP peering agreements), emergency services peering points, and the like. BIGCF122 may route calls to the IMS core when the call is intended for IMS subscribers or when IMS services are to be invoked, or may bypass IMS core elements (P-CSCF 106, I-CSCF104, S-CSCF102, HSS 108, etc.) when the call is intended for non-IMS subscribers and the calling or called party is not invoking IMS services. BIGCF122 may route calls to PSTN-based endpoints to BGCF120 and route calls to IP-based endpoints (e.g., to wholesale, IP-based carriers, etc.) directly to I-SBCs 150 associated with the IP-based endpoints. BIGCF122 may include static routing policies for routing emergency calls to BGCF 120. BIGCF 120 may also support static routing policies for routing non-emergency calls from a determined origin (e.g., a wholesale gateway requiring prepaid authorization for non-emergency calls) to a prepaid service controller. If a call is invoked from and/or to an IMS subscriber or IMS service, BIGCF122 may route the call to an IMS platform using I-CSCF104 to invoke the call and/or called party features.

BIGCF122 may include a set of configuration data. For example, BIGCF122 may maintain a list of service hosts. If the request uniform resource identifier (R-URI) in the incoming request does not identify one of the service hosts, BIGCF122 may delegate the call externally to an address resolved by a Domain Name Service (DNS) Service (SRV) record, or reject the call by sending a Session Initiation Protocol (SIP)403 response (or other type of message) unless the call is an emergency call. In this manner, BIGCF122 may reject calls destined for unknown entities.

BIGCF122 may also include a list of emergency prefixes per country. For example, BIGCF122 may store prefix 911 for the united states. BIGCF122 may store a non-geographic numbered list (e.g., 800, 411, etc.) for each country of origin. Via this list, BIGCF122 may route the call directly for PSTN breakout.

BIGCF122 may further store a list of originating hosts (e.g., gateway Uniform Resource Locators (URLs)), from which calls may be expected. If the call is not from one of the hosts in the originating host list (according to the next highest path or first path), BIGCF122 may reject the request. The originating host based data may include a plurality of data elements. For example, the data element may include a gateway IP address for one or more hostnames. The originating host may point to prefix/suffix information to standardize the calling party number. For example, the wholesale gateway may have a rule to indicate that if 7 digits are given at the calling party number, then the calling party number is prefixed with + 1732. The suffix information may indicate how many digits are considered after the suffix.

The originating host may identify the location of the calling party identity indicator. For example, the originating host may identify from which header in the SIP INVITE message the calling party information was obtained.

The data element may also include the country or location of the gateway. This location may be used by BIGCF122 to standardize the called party number according to the country of call origination. The location of the gateway may also be used by BIGCF122 to identify the location of the gateway to which the emergency call is to be routed.

The data element may further include a list of blocking prefixes from each originating host. For example, 1900 may indicate that a "1-900" call is blocked by this gateway. The data element may further include an outbound route for each originating host. For example, non-emergency calls from a given host may be routed to a configured host, such as a prepaid service controller.

In addition to the above data, BIGCF122 may be configured with the following data: a variable that allows or denies the handling of the INVITE, wherein the request URI does not match one of the hosts of the configured service; an option for accepting or rejecting each originating domain or IP address of the request; an option for processing the determined SIP request; a prefix per origin that is not allowed; static routing rules based on prefix matching; a group of servers pointing to an ENUM server farm (farm); a set of servers directed to an I-CSCF server farm for routing to an IMS core; a group of servers directed to a BGCF server farm for bypassing the IMS core and routing directly to BGCF 120; a server group directed to an emergency services location server farm (e.g., a U.S. emergency services network portion); an option for specifying that the determined message is to be sent to an error log or screen display; options for running and stopping the gateway in BIGCF 122; country codes required for number standardization; number normalization rules (e.g., based on originating gateway); an option to enable or disable the recording category; an option for enabling or disabling an alert; and an option for enabling or disabling the metrics.

In one implementation, BIGCF122 may be connected to I-CSCF104, SLG 116, NGW 118, and BGCF120 via SIP interfaces. In addition, BIGCF122 may connect to ENUM 146 via a DNS protocol interface.

C. Media Resource Function (MRF)

The IMS core may provide shared multimedia services. Examples of multimedia services (or applications) include presentation announcements, audio/video recording and playback, Interactive Voice Response (IVR), fax reception and transmission, Automatic Speech Recognition (ASR), text-to-speech (TTS) sessions, multimedia conferencing, customized ring tones, push-to-talk over cellular (PoC), video messaging, and so forth. MRF 124 may be part of the IMS platform and may support services requiring multimedia streams.

As illustrated in fig. 1, MRF 124 may include MRFC 126, MRFP 128, and MRB 130. MRFC 126 and MRFP 128 are IMS resources that provide support for bearer-related services (e.g., multi-party sessions, announcements to users, bearer transcoding, etc.). MRFC 126 may provide services related to bearer control. MRFP 128 may provide user plane resources that may be requested and indicated by MRFC 126. MRB 130 may provide resource management functions that can allow media resources to become shared resources among multiple applications.

D. Application server

Application server 132 may include one or more servers that provide enhanced audio, video, messaging, and data services within the application layer of system 100. The application server 132 is accessible by users of the IMS platform and provides value-added multimedia services to those users. The application server 132 may submit a fee to the IMS platform for the service, which the application server 132 provides to the IMS user community.

Two types of application servers 132 that may be used within the system 100 may include micro-applications and macro-applications (or macro-application services). Micro applications may be provided on a common service delivery platform through the use of a Service Creation Environment (SCE) 134. Micro-applications may include a wide variety of enhanced multimedia services that require rapid development and deployment cycles. Examples of macro application services include hosted IP CENTREX (HIPC)136, Unified Messaging (UM)138, and carrier application services 140.

HIPC 136 may correspond to a type of private branch exchange (PBX) service in which switching occurs at a local telephone office rather than at a corporate site where a conventional PBX is located. In one implementation, HIPC 136 may be replaced or supplemented with a SIP voice feature server. Unified messaging 138 may allow a user to be able to retrieve and send voice messages from a single interface regardless of technology (e.g., telephone, personal computer, etc.) and other unified messaging services (e.g., fax deposit retrieval, voice to email, etc.). Carrier AS 140 may facilitate tool-less call processing.

E. Service Creation Environment (SCE)

SCE 134 provides the basis for the rapid development of next generation services. SCE 134 may support Java Specification Request (JSR)116 SIP servlets and an external Application Programming Interface (API) suite for developers to gain access to the IMS platform. A single SCE 134 may support multiple macro application servers and may support building micro applications.

F. Service

The IMS core may support a number of different services such as GLMS 142, presence 144, and ENUM server 146. GLMS 142 may include one or more services that allow group list creation, management, and use across multiple applications within the IMS. GLMS 142 may enforce access and visibility rules. Presence 144 may include one or more services for automating the task of aggregating presence and availability information. Presence 144 may inform one user of the status of the availability and willingness of another user for communication. Presence server 144 may use a Presence User Agent (Presence User Agent PUA) to manage the Presence of IMS users and process Presence subscription requests. For example, an application or IMS subscriber may act as a watcher, which is an entity that subscribes to presence information provided by presence server 144. ENUM server 146 may provide conversion of e.164 to SIP URIs. BIGCF122 and S-CSCF102 may query ENUM server 146 to determine the next hop for the call. In some implementations consistent with the principles of the invention, BIGCF122 may perform ENUM queries for calling and called number resolution.

G. Boundary element

The IMS core may include one or more Session Border Controllers (SBCs) to provide control of the boundaries between different service provider networks, to provide signaling protocol interworking between SIP-based IMS platforms and other service provider networks, to control the transport boundaries between service provider networks, and to provide usage measurements and quality of service (QoS) metrics to media streams. Two types of SBCs that may be implemented in the IMS platform are Access Session Border controller (A-SBC)148 and I-SBC 150.

a-SBC 148 may correspond to an entry point to the IMS platform for Customer Premises Equipment (CPE) traffic, except for the wholesale gateway. A-SBC 148 may provide SIP aware firewall capabilities for supporting Network Address Translation (NAT), preventing denial of service (DoS) attacks, and performing other security enforcement features. A-SBC 148 may be the first SEP event standard point in front of the IMS platform.

An internetworking session border controller (I-SBC)150 may act as a connection point between the IMS platform and the wholesale gateway and between the IMS platform and the IP peering VoIP carrier. I-SBC150 may provide SIP standardization and topology hiding and interconnect network gateway (THIG) services. In one implementation, I-SBC150 may be replaced or supplemented with a Border Gateway Function (BGF).

H. Policy (es)

The system 100 may include a plurality of policy components. For example, system 100 as illustrated in fig. 1 may include policy engine 152, PDF 154, and RM 156. Policy engine 152 may include one or more rule-based engines for managing subscriber access to the IMS platform, subscriber access to resources, and routing decisions for several different types of event requests made within the IMS platform. In one implementation, policy engine 152 may provide decision logic to decision and policy points in the IMS platform. PDF 154 may correspond to a Policy Decision Point (PDP) for service-based local policy control. PDF 154 may make policy decisions based on session and media related information. PDF 154 may exchange this decision information with another IMS element (such as A-SBC 148 or I-SBC 150) to control the traffic and characteristics of the communication link. Component level policies may be enforced using RM 156. As illustrated in FIG. 1, RM 156 may be associated with, for example, S-CSCF102, BIGCF122, A-SBC 148, and I-SBC 150. In one implementation, RM 156 may store and execute policy decisions related to the location with which RM 156 is associated.

I. Charging Function (CF)

CF 158 may include a unified system for influencing offline charging and online charging. Offline charging is a process in which charging information for network resource usage is collected concurrently with the resource usage. Charging information may be conveyed via a chain of CFs 158. At the end of this process, a Call Detail Record (CDR) file may be generated by the network, which is then forwarded to the billing domain of the network operator for subscriber billing processing, which may include rating and rendering.

Online charging is a process in which charging information may affect the services provided in real time. Supporting this capability requires a direct interaction between the charging mechanism and the session control mechanism of the network. Examples of online charging include prepaid calling card usage.

The CDF 160 may compile the billable events collected from the IMS components into a single CDR for offline billing activities. CDF 160 may collect billable events from a Charging Trigger Function (CTF), which may be associated with a component of system 100 and communicate billing data to CGF 162 after the CDR is created.

CGF 162 may act as a gateway between an offline charging system, an online system, and an external post-processing system (such as a billing domain).

J. General User Profile (GUP)

Information related to IMS subscribers can be in many formats, managed by many network elements and regulatory agencies. This makes access to the data more complicated for the user, the network element and the value added service provider. A Generic User Profile (GUP) addresses these issues and provides a generic conceptual description of subscriber data. The GUP server may provide means for accessing the data described in the GUP.

Exemplary configuration of an ENUM Server

Fig. 2 illustrates an exemplary configuration of ENUM server 146. As illustrated, ENUM server 146 may include a bus 210, processing logic 220, a memory 230, an input device 240, an output device 250, and a communication interface 260. It should be appreciated that ENUM server 146 may include other components (not shown) that facilitate receiving, transmitting, and/or processing data. Further, it should be understood that other configurations are possible.

Bus 210 may allow communication among the components of ENUM server 146. Processing logic 220 may include any type of processor or microprocessor for interpreting and executing instructions. In other implementations, the processing logic 220 may be implemented as or include an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or the like. Memory 230 may include a Random Access Memory (RAM) or other type of dynamic memory for storing information and instructions for execution by processing logic 220, a Read Only Memory (ROM) or other type of static storage device for storing static information and instructions for processing logic 220, and/or other types of magnetic or optical recording media and their corresponding drives for storing information and/or instructions.

Input device 240 may include a device for allowing an operator to input information to ENUM server 146, such as a keyboard, keypad, mouse, pen, microphone, one or more biometric mechanisms, and the like. Output device 250 may include a device for outputting information to an operator, such as a display, a speaker, and so forth.

Communication interface 260 may include any transceiver-like mechanism for enabling ENUM server 146 to communicate with other devices and/or systems. For example, communication interface 260 may include mechanisms for communicating with other components within system 100.

As described in detail below, ENUM server 146 may perform processing associated with routing calls to and from parties. ENUM server 146 may perform these and other functions in response to processing logic 220 executing software instructions contained in a computer-readable medium, such as memory 230. A computer-readable medium may be defined as one or more memory devices and/or carrier waves. The software instructions may be read into memory 230 from another computer-readable medium or another device via communication interface 260. The software instructions contained in memory 230 may cause processing logic 220 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, systems and methods according to the principles of the present invention are not limited to any specific combination of hardware circuitry and software.

Exemplary processing

Numbers in the e.164 format are globally unique, language independent identifiers for resources on a public telecommunications network that can support many different services and protocols. E.164 is controlled by the International Telecommunications Union (ITU). Currently, many IMS subscribers who wish to establish a session, as opposed to URIs, can be identified via e.164 numbers (also referred to as subscriber public IDs). Accordingly, the system 100 may support establishing a session to a terminal identified by an e.164 number, as described in detail below.

System 100, and in particular ENUM server 146, may perform processing associated with performing ENUM-related mappings, such as mappings from e.164 numbers to URIs. This process may be referred to herein as "infrastructure ENUM. Infrastructure ENUM is based on the format and procedures defined in Internet Engineering Task Force (IETF) request for comments (RFC) 3761. However, ENUM server 146 applications for those formats and procedures (i.e., the formats and procedures specified in RFC 3761) may not strictly follow the objects defined in RFC 3761. For example, RFC 3761 defines the conversion of e.164 numbers to URIs, which are used to identify individual subscribers (called record addresses or AORs). These URIs can then be routed using the mechanisms in RFC-3261 and RFC-3263. This implementation is sometimes referred to as "subscriber ENUM. Conceptually, user ENUM is an end-user service. Thus, the presence and nature of the translation logic with a given e.164 number may be determined by the subscriber to whom the number is assigned. In contrast, infrastructure ENUM is a network routing mechanism. Infrastructure ENUM translation typically exists for all active e.164 numbers. The details of the translation of a given number may be determined by the entity to which the number is assigned, for example by a national number plan administrator, an agent working on behalf of such an entity, or an entity that has been trusted to be responsible for number assignment. Infrastructure ENUM utilizes similar translation techniques as subscriber ENUM, but the generated URIs do not necessarily identify the end-users. The translation logic associated with a given e.164 number may identify (directly or indirectly) the network element to which the session request should be forwarded for subsequent processing. ENUM server 146 and other components in the system perform infrastructure ENUM-related processing and analyze any potential conflicts between subscriber ENUM processing and infrastructure ENUM processing.

Fig. 3 is a block diagram illustrating exemplary portions of system 100 associated with performing ENUM-related processing, and in particular infrastructure ENUM-related processing. Referring to FIG. 3, a portion of system 100 is illustrated including S-CSCF102, I-CSCF104, P-CSCF 106, BGCF120, BIGCF122, ENUM server 146, and Operation Support System (OSS)/Business Support System (BSS) 310. ENUM server 146 may be coupled to S-CSCF102 and BIGCF 122. S-CSCF102 and BIGCF122 may communicate with ENUM server 146, for example, via DNS protocols. S-CSCF102, I-CSCF104, P-CSCF 106, BGCF120, and BIGCF 121 may communicate with each other using, for example, SIP signaling. ENUM server 146 is also shown coupled to OSS/BSS 310. In an exemplary implementation, OSS/BSS310 may send provisioning and/or configuration information to ENUM server 146 and ENUM server 146 may send logs, alarms, and/or various metrics to OSS/BSS310, as described in more detail below.

ENUM server 146 performs a number of functions associated with infrastructure ENUM. Infrastructure ENUM related processing may serve internal routing functions and intermediate carrier routing functions. For example, ENUM server 146 may translate an e.164 routing number, including a pooled (ported) and/or ported number, to a URI for routing purposes. ENUM server 146 may also include a mechanism for populating an ENUM database (not shown in fig. 3) with Naming Authority Pointer (NAPTR) records. ENUM server 146 may further provide alarm and performance management functions and configuration management functions associated with OSS/BSS 310. ENUM server 146 may further provide DNS server functionality in accordance with RFC 1034 and RFC 1035.

As described above, ENUM server 146 provides internal routing information as well as routing information for use between a set of peer service providers, such as VoIP service providers. For example, infrastructure ENUM may be intended for service provider internal routing and/or use between a set of peer VoIP service providers. The DNS NAPTR query may be based on a common Top Level Domain (TLD) agreed upon by the peer partner. In this configuration, each side manages its own ENUM translation data within a group of ENUM servers to which it has administrative rights. Queries for translation information associated with numbers assigned to other carriers are forwarded to and answered by servers associated with those carriers. Alternatively, peer partners may share their ENUM translation data within a group of servers to which they have administrative privileges and under their selected "private" TLD, each of them storing data from parties with whom it has performed a peer-to-peer agreement. In either implementation, the selected TLD may not be the e164.arpa field, so that it does not conflict with the user ENUM. The TLD may also use non-public roots, such as roots that are not.com,. edu,. gov, etc., to ensure that the data is not accessible to the public.

In configurations involving shared TLDs, a DNS peer provider accessible by system 100 and its VoIP peer partners may host the domain root. For example, fig. 4A illustrates ENUM root server 410 coupled to e.164 database 420 and e.164 database 430. E.164 database 420 may be implemented within ENUM server 146 or may be a database accessible by ENUM server 146. E.164 database 430 may be associated with a VoIP peering partner. E.164 database 420 may receive an ENUM query from IMS SIP server 425. IMS SIP server 425 may represent, for example, BIGCF122, S-CSCF102, or another SIP server in system 100. If a particular e.164 number is not included in e.164 database 420, e.164 database 420 may perform hierarchical, recursive DNS resolution by communicating with ENUM root server 410. Similarly, e.164 database 430 may utilize ENUM root server 410 to perform hierarchical, recursive DNS resolution. The ENUM peer service provider may also provide additional services, such as supporting routing of ported numbers.

In a configuration where each peer partner stores infrastructure ENUM translation for its own number and the number assigned to its peer partner under a private TLD, each partner may determine a URI for each e.164 number or e.164 block of numbers that it is entitled to, which should be translated to the URI in response to a query from each peer partner. Each partner may then generate the corresponding data and provide the appropriate subsets to each other partner. Each partner, in turn, may expect to receive equivalent transformation data from the other partners, which may be stored in local database 420. This process of expressing and exchanging infrastructure ENUM translations may be repeated periodically, which may be facilitated by a DNS peer provider accessible by system 100 and its VoIP peer partners. Such DNS peer providers may also provide some value-added functionality, such as the standardization of ported and pooled numbers. E.164 database 420 may receive an ENUM query from IMS SIP server 425. IMS SIP server 425 may represent, for example, BIGCF122, S-CSCF102, or another SIP server in system 100. Since the e.164 database 420 contains translation data from all peer partners, it can analyze this query without requiring access to any external data storage device. Similarly, e.164 database 430 may analyze all queries from SIP servers in its domain without requiring access to an external data storage device.

In an exemplary implementation of the "shared TLD" configuration, the URI translated by a given e.164 number is different if assigned to the entity responsible for the system 100 than if the number was not assigned to the entity. For example, a URI returned in response to a query specifying a number assigned to an entity responsible for e.164 database 420 may identify an element within system 100, while a URI returned in response to a query specifying a number assigned to another operator may (at the operator's discretion) identify an element in the operator's network. System 100 may implement a policy using what is referred to herein as a "split DNS" configuration. Split DNS can use two sets of DNS servers, one for internal use and one for external use.

For example, fig. 4B illustrates a split DNS implementation. Referring to fig. 4B, system 100 may include an external DNS server 440, an e.164 database 442, an internal DNS server 450, and an e.164 database 420. A firewall or other security device may be located between servers 440 and 450 to prevent unauthorized access to DNS server 440. The VoIP peering partner illustrated to the right of the dashed line in fig. 4B may be configured in a manner similar to system 100. External DNS server 440 may connect to ENUM root server 410 and may receive queries from outside system 100. External DNS server 440 may also be coupled to e.164 database 442. Internal DNS server 450 and/or e.164 database 420 may be accessible internally from system 100. Internal DNS server 450 may be populated with data that gives details of routing calls within system 100. The set of e.164 numbers used to configure the translation in external DNS server 440 may overlap with the set of e.164 numbers used to configure the translation in internal DNS server 450. However, the URIs returned by DNS servers 440 and 450 may be different. For example, external DNS server 440 may return the URI of an I-SBC within system 100 in response to a query specifying a number assigned to be owned by an entity responsible for system 100, while internal DNS server 450 may return the URI of an I-CSCF104 or wholesale gateway address.

Devices within system 100 may be configured to use internal DNS server 450. Internal DNS server 450 may forward queries that it cannot analyze to external DNS server 440. External DNS server 440 may use ENUM root server 410 and DNS servers for VoIP service provider peering (e.g., VoIP peering partners) to participate in DNS hierarchy resolution.

Since subscriber ENUM and infrastructure ENUM serve different needs and are populated with different data, there may be differences between results from subscriber ENUM and infrastructure ENUM queries for the same e.164 number. These differences may result in identifying different routing logic and possibly different providers for the services to which the user has subscribed. To analyze these differences, system 100 may treat subscriber ENUM as a terminating network problem. That is, only the service provider to which a particular number is assigned may perform a subscriber ENUM lookup. This helps ensure that the terms of the peer-to-peer agreement are respected, thereby avoiding a situation in which user ENUM results may lead to bypassing of the VoIP peer-to-peer network.

System 100 may also use only infrastructure ENUM routing and IMS service configuration for internal IMS subscribers, thereby maintaining vertical service integration. An entity/service provider associated with system 100 may also utilize infrastructure and user ENUM routing and user ENUM service configuration for internally owned non-IMS subscriber numbers. This allows service providers to offer non-IMS VoIP services, where user ENUM may play a more important role.

Fig. 5 is a flow chart illustrating exemplary processing associated with a call received by system 100. Processing may begin with BIGCF122 receiving a call (act 510). The call may come from an external origin, such as a wholesale subscriber, into a PSTN gateway, class 3 network, class 5 network, etc., for example. BIGCF122 may then perform an infrastructure ENUM lookup based on the calling party number and the called party number. For example, BIGCF122 may send a DNS NAPTR query to ENUM server 146 identifying the calling party number (act 510). BIGCF122 may also or alternatively send a separate DNS NAPTR query to ENUM server 146 identifying the called party number (act 510). In yet another implementation, BIGCF122 may send a single DNSNAPTR query to ENUM server 146 that includes both the calling and called party numbers. ENUM server 146 may receive a DNS NAPTR query (act 520). ENUM server 146, along with BIGCF122, may determine whether the call is to be serviced by the IMS core (act 530).

For example, in one implementation, the call may not be served by the IMS core if the calling party number is not associated with an IMS profile that invokes an IMS application, the called party number is not associated with an IMS subscriber, or the called party is not associated with an IMS profile that invokes an IMS application. It is assumed that the call is not served by the IMS core. In this case, ENUM server 146 may return a response to BIGCF122 that includes a URI identifying an IMS core out-element (act 540). For example, ENUM server 146 may identify a URI (e.g., sip: CdPN @ gateway. w holaler. com, where "CdPN" represents a called party e.164 number) for pointing to a wholesale subscriber gateway.

BIGCF122 may receive a response from ENUM server 146 and route the call accordingly. In this case, the call may be routed outside the IMS core. That is, BIGCF122 routes the call to the entity identified by the URI in the ENUM query response, which has the effect of bypassing the IMS core in this example (act 550). For example, if the URI in the ENUM query response identifies a wholesale gateway or an IP-based carrier termination, BIGCF122 may forward the call (if no URI is returned in the ENUM query response) to BGCF120 for routing to the appropriate PSTN termination or the appropriate I-SBC 150.

If the call is to be routed to the IMS core, ENUM server 146 may return a response identifying the element in the IMS core (act 560). For example, ENUM server 146 may return a URI (e.g., sip: CdPN @ icscfl.21.sip.com) identifying an element in the IMS core. In this example, the message indicates that the call is to be routed to I-CSCF 104.

BIGCF122 may receive the response with the URI and route the call to the IMS core (i.e., I-CSCF104 in this example) to terminate subscriber feature processing (act 570). The terminating subscriber feature processing may include, for example, applications executed by the IMS core, such as text-to-speech conversion systems, IVR, ASR, multimedia conferencing, and the like. In various cases, appropriate elements in the IMS core may invoke appropriate IMS services, forward requests to appropriate elements, and/or forward the call to appropriate IMS subscribers.

The processing described above with respect to fig. 5 relates to inbound calls received from outside the IMS core, for example, from non-IMS subscribers. Fig. 6 illustrates exemplary processing associated with an inbound call received by an IMS core from a registered subscriber.

Processing may begin with receiving a call from a registered IMS subscriber (act 610). A call message may be sent, for example, from P-CSCF 106 to, for example, S-CSCF 102. S-CSCF102 may obtain a service profile for the originating user (act 620). For example, S-CSCF102 may access HSS 108 to determine whether HSS 108 includes an IMS profile for the destination number (i.e., the called party number). Assume that S-CSCF102 cannot find an IMS profile for the called party number in HSS 108.

S-CSCF102 may then perform an infrastructure ENUM lookup based on the called party number (act 630). For example, S-CSCF102 may send a DNS NAPTR query to ENUM server 146 that includes the called party number. ENUM server 146 may receive the DNSNAPTR query and generate a URI, for example, for pointing to a VoIP peering partner gateway (act 640). Alternatively, the URI may point to a PSTN destination gateway. ENUM server 146 may then forward the response to S-CSCF 102.

Assume that ENUM server 146 generates a URI for pointing to a VoIP peering partner gateway. S-CSCF102 may then use the VoIP peer partner gateway name as a search key to look up a URI in a local table that identifies the I-SBC, for example (act 650). S-CSCF102 may then identify the URI from the local table and add a routing header to the signaling message that specifies this URI (act 650). S-CSCF102 may then route the call to the peer partner gateway via the I-SBC determined in act 650 (act 660).

In some implementations, an infrastructure ENUM lookup based on the called number at act 630 may result in ENUM server 146 returning a "null" response. This may occur, for example, when the called number is out of service. In this case, S-CSCF102 may terminate the call.

As described above, ENUM server 146 supports route lookup for IMS subscribers and non-subscribers. ENUM server 146 may also perform a number of other functions/processes. For example, ENUM server 146 may implement a Dynamic Delegated Discovery System (DDDS) as defined in IETF RFCs 3401, 3402, 3403, 3404, and 3405. ENUM server 146 may perform batch processing for uploading mappings of e.164 numbers and NAPTR resource records. ENUM server 146 may also include a management interface for allowing manual updates to e.164 and NAPTR mappings.

ENUM server 146 may further perform validating the format of URIs in NAPTR resource records and rejecting NAPTR resource records containing incorrect URI formats. ENUM server 146 may also provide support for mapping an e.164 number to multiple NAPTR resource records.

ENUM server 146 may also provide support for "SIP" ENUM service and support for "VOID" ENUM service as specified in IETF RFC 3764. ENUM server 146 may further support mapping policies such that NAPTR records may be resolved using arbitrary numbers, e.g., up to 15 digits. ENUM server 146 may also support negative response caching and support records (i.e., wildcards) per RFC 1034.

As discussed in fig. 5 and 6, various scenarios coupled with operator policies manage responses from ENUM server 146. Table 1 below provides exemplary ENUM responses for various different numbers.

Number type	ENUM response
		IMS subscriber number	URI pointing to I-CSCF
VoIP wholesale number-no IMS feature	URI pointing to VoIP wholesale interconnection gateway
		VoIP wholesale number with IMS features	URI pointing to I-CSCF
Number owned by VoIP peer partner	URI pointing to peer partner interconnection gateway
		Numbers owned by entities associated with the IMS that are not operational	Enumservice“VOID”
Numbers not registered in infrastructure ENUM	DNS NXDOMAIN (without such a Domain) response

Table 1 ENUM response summary

BIGCF122 may use responses from both NAPTR queries (i.e., called number query and calling number query) to route calls to the IMS core (e.g., towards I-CSCF104) or away from the IMS core (e.g., towards BGCF 120).

As described above, infrastructure ENUM configuration for a group of operators (i.e., "peering partners") that provide IP-based services (e.g., VoIP) and wish to exchange associated information flows via IP may be implemented using shared top-level domains (TLDs) or private TLDs. Shared TLD configuration can be implemented using a split DNS architecture. In a shared TLD or private TLD configuration, the response returned to the query from the peer partner may be different from the response returned from within the system 100 in response to the query.

In addition, to operate in a peer-to-peer environment, ENUM server 146 may provide the following security features:

a) the data populated in the DNS table may not include confidential information about the subscriber;

b) data that may be queried by external parties may not include information to reveal proprietary attributes of system 100. For example, externally exposed URIs (corresponding to those of the I-SBC) may use names that do not reveal the network topology;

c) internal ENUM server 146 may be configured to accept DNS queries only from a set of components of approved system 100. This can be achieved by directly configuring the server or by means of an access control table implemented in the network security control point. The set of approval components for the internal DNS server may include, for example, S-CSCF102 and BIGCF 122. In addition to the above, the set of components approved for use by the external ENUM server may be limited to a set of devices explicitly identified by the VoIP peering partner.

In a "private TLD" configuration, OSS/BSS310 (fig. 3) may populate an ENUM peer-to-peer service provider database with ENUM data associated with system 100. The peer service provider can extend this data with local number portability information and can push the consolidated data to the real-time name server.

ENUM server 146 may also provide for viewing in real-time the following performance-related system information: system uptime, successful query profile, unsuccessful query profile, and system utilization percentage (processor and storage). ENUM server 146 may further provide logs and metrics to assist in performance management.

For example, ENUM server 146 may record requests and responses with configurable recorded data content, i.e., the fields of the log may be configurable. The record may be written to a persistent storage device, such as a log file, having a periodically incremented file identifier. File period and minimum/maximum file size may be configurable and ENUM server 146 may support logging to offline platform persistent storage as an option.

ENUM server 146 may also support multiple configuration management features. For example, ENUM server 146 may support, for example, Simple Object Access Protocol (SOAP) or clear text XML/HTTP to provide an Application Programming Interface (API) for allowing full remote configuration of ENUM server 146, including loading and changing DNS records. ENUM server 146 may also support a command line based configuration and management console, a Graphical User Interface (GUI) based configuration and management console, and a configuration and management console capable of managing multiple instances of ENUM server 146 from a single console and batch processing of uploaded NAPTR resource records.

ENUM server 146 may also support error management functions. For example, ENUM server 146 may generate an alert identifying a problem in at least the following respects: network interface, disk capacity utilization, and unsuccessful query count exceed configurable thresholds. ENUM server 146 may also provide a tool for observing system information related to faults in real-time, such as alarm counts by severity.

Conclusion

Embodiments described herein are for routing calls via or outside of the IMS core. For example, if the call involves an IMS subscriber or invokes an IMS application, the ENUM server may provide routing information indicating that the call is to be routed via the IMS core. However, if the call does not involve an IMS subscriber or invoke an IMS application, the ENUM server may identify routing information that would result in routing outside the IMS core.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims that follow. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

For example, a single ENUM server is illustrated in fig. 1 for simplicity. In some implementations, multiple ENUM servers may be used. In addition, the call routing scenario described above is for explanatory purposes only. Other call/call routing scenarios involving IMS subscribers, non-IMS subscribers, peers, PSTN parties, etc. may also be handled in implementations consistent with the invention.

Additionally, while series of acts have been described with regard to fig. 5 and 6, the order of the acts may be varied in other implementations consistent with the invention. Further, non-dependent acts may be implemented in parallel.

It will be apparent to one of ordinary skill in the art that aspects of the invention may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects consistent with the principles of the invention is not limiting of the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code-it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.

Furthermore, certain portions of the invention may be implemented as "logic" that performs one or more functions. This logic may include hardware, such as a processor, microprocessor, application specific integrated circuit, or field programmable gate array, software, or a combination of hardware and software.

The inventive aspects described herein are generally applicable to multimedia sessions implemented via an internet protocol infrastructure that uses e.164 numbers to identify endpoints. The frequent use of terminology associated with telephony (e.g., "calling") and the historical association of e.164 numbers with such services limit the scope or applicability of the present invention.

No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. An unlimited number of items is intended to include one or more items. Where only one item is referred to, the terms "a" and "an" or similar language is used. Furthermore, the phrase "in accordance with" is intended to mean "in accordance with at least in part" unless explicitly stated otherwise.

Claims (21)

1. A system, comprising:

at least one device configured to:

receiving at least one query from an Internet protocol multimedia subsystem (IMS) component, the at least one query being associated with a call, and

forwarding routing information to the IMS component based on the at least one query, the routing information indicating: when the calling party does not invoke IMS-related services, the called party does not invoke IMS-related services, and the called party is not an IMS subscriber, the processing associated with routing the call will bypass the portion of the IMS associated with providing IMS-related services.

2. The system of claim 1, wherein the at least one device comprises a telephone number mapping server configured to:

the e.164 number is converted to a uniform resource identifier.

3. The system of claim 2, wherein the telephone number mapping server is configured to:

receiving a first query, the first query including a calling party number,

identifying a first uniform resource identifier for the calling party number,

receiving a second query, the second query including a called party number,

identifying a second uniform resource identifier for the called party number, and

forwarding the first and second uniform resource identifiers to the IMS component.

4. The system of claim 1, wherein the at least one device is further configured to: routing the call via a portion of the IMS associated with providing IMS related services when the calling party invokes IMS related services, the called party invokes IMS related services, or the called party is an IMS subscriber.

5. The system of claim 1, wherein the portion of the IMS associated with providing IMS-related services includes a plurality of call session control components, and the routing information does not identify any of the call session control components when the call is to bypass the portion of the IMS associated with providing IMS-related services.

6. The system of claim 1, wherein the at least one device comprises:

a telephone number mapping server, and

a database for storing e.164 numbers and corresponding uniform resource identifiers, the telephone number mapping server being configured to map received e.164 numbers associated with the calls to uniform resource identifiers.

7. The system of claim 6, wherein the phone number mapping server is further configured to:

communicating with a root telephone number mapping server associated with the peer service provider and a telephone number mapping server operated by the peer partner to identify a uniform resource identifier associated with the call.

8. The system of claim 6, wherein the phone number mapping server is further configured to:

storing telephone number mapping information of numbers belonging to a local carrier and a group of peer-to-peer partners, and

the query is solved for numbers belonging to the local carrier and the group of peer partners without communicating with other servers.

9. The system of claim 1, wherein the at least one device comprises:

a first domain name system server configured to store an E.164 number associated with the IMS, and

a second domain name system server configured to identify uniform resource identifiers associated with parties outside the IMS.

10. The system of claim 9, wherein the second domain name system server is configured to communicate with an entity outside the IMS to resolve a telephone number mapping query associated with a call received by a party outside the IMS.

11. A method, comprising:

receiving a telephone number mapping query, the query being associated with a call;

generating routing information based on the query; and is

Forwarding said routing information to a control device, said routing information indicating: when a calling party associated with the call does not invoke IMS services, a called party associated with the call does not invoke IMS services, and the called party is not an IMS subscriber, processing associated with routing the call will bypass a core portion of an Internet Multimedia Subsystem (IMS).

12. The method of claim 11, wherein the generating routing information comprises:

mapping a first e.164 number associated with the calling party to a first uniform resource identifier, and

a second e.164 number associated with the called party is mapped to a second uniform resource identifier.

13. The method of claim 12, further comprising:

forwarding the first and second uniform resource identifiers to the control device;

receiving, by the control device, the first and second resource identifiers; and is

Routing the call by bypassing a core portion of the IMS in accordance with the first and second uniform resource identifiers.

14. The method of claim 11, further comprising:

routing the call via a core portion of the IMS when the calling party invokes an IMS service, the called party invokes an IMS service, or the called party is an IMS subscriber.

15. The method of claim 11, wherein the generating routing information comprises:

communicating with a root telephone number mapping server to identify a uniform resource identifier associated with the call.

16. The method of claim 11, wherein the generating routing information comprises:

accessing a first database configured to store E.164 numbers associated with the IMS, and

accessing a second database configured to store E.164 numbers associated with parties outside of the IMS when the first database does not store E.164 numbers associated with the call.

17. The method of claim 16, wherein the generating routing information further comprises:

when the call is from a party outside the IMS, communicating with entities outside the IMS to resolve the query.

18. A method, comprising:

receiving a telephone number mapping query, the query being associated with a call from a calling party to a called party;

identifying a first uniform resource identifier associated with the calling party;

identifying a second uniform resource identifier associated with the called party;

forwarding the first and second uniform resource identifiers to a control device; and is

Routing the call to the called party when the calling party does not invoke IMS-related services, the called party does not invoke IMS-related services, and the called party is not an IMS subscriber, wherein the routing bypasses a portion of the IMS associated with providing IMS-related services.

19. The method of claim 18, wherein the identifying a first uniform resource identifier comprises mapping an e.164 number associated with the calling party to the first uniform resource identifier, and the identifying the second uniform resource identifier comprises mapping an e.164 number associated with the called party to the second uniform resource identifier.

20. The method of claim 18, wherein the identifying at least one of the first uniform resource identifier or the second uniform resource identifier comprises:

accessing a first database configured to store E.164 numbers associated with the IMS, and

accessing a second database configured to store E.164 numbers associated with parties outside of the IMS when the first database does not store E.164 numbers associated with the call.

21. The method of claim 18, wherein the identifying at least one of the first uniform resource identifier or the second uniform resource identifier comprises:

when the calling or called party is not an IMS subscriber, communicating with entities other than the IMS to resolve the query.