Network routing
Summary by NHIP
IMS Routing System
The system routes call requests to an Internet Protocol Multimedia Subsystem core or bypasses it based on whether the calling and called parties are served by that core. It determines service status by querying a telephone number mapping database or sending domain name service queries for each party.
Claim Score by NHIP
Abstract
At least one device receives a call request from a calling party to a called party. The device routes the call request to an Internet Protocol Multimedia Subsystem (IMS) core when a first condition is met and bypasses the IMS core when a second condition is met.
Term
4.2 yearsleft in the term
Expires 11 December 2030, including 1,597 days of term adjustment.
- Priority
- Filed
- Granted
- Today
- Expires
16 claims: 3 independent, 13 dependent
- 1Broadest claimClaim Score 80, broad(NHIP)A system comprising:at least one device to: receive a call request from a calling party to a called party, determine whether the calling party or the called party is served by an Internet Protocol Multimedia Subsystem (IMS) core, route the call request toward the called party, and bypassing the IMS core when the calling party and the called party are not served by the IMS core, and route the call request to the IMS core when the calling party is not served by the IMS core and the called party is served by the IMS core.
- 10A method performed by a network device, the method comprising:receiving, by a communication interface of the network device, a call from a first party for a second party;determining, by a processor of the network device and based on receiving the call, whether the first party is served by an Internet Protocol Multimedia Subsystem (IMS) core;determining, by the processor of the network device and based on receiving the call, whether the second party is served by the IMS core;routing, by the communication interface, the call toward the second party and bypassing the IMS core when the first party and the second party are not served by the IMS core;and routing, by the communication interface, the call request to the IMS core when the first party is not served by the IMS core and the second party is served by the IMS core.
- 15A system comprising:at least one device to: receive a call request from a calling party to a called party, neither the calling party nor the called party being an Internet Protocol Multimedia Subsystem (IMS) user, evaluate whether the calling party has invoked an IMS application, evaluate whether the called party has invoked an IMS application, route the call request to the IMS core when at least one of the calling party or the called party has invoked the IMS application, bypass the IMS core when the calling party and the called party have not invoked the IMS application, receive another call request, determine that the other call request is an emergency call request, and bypass an IMS core based on the other call request being the emergency call request.
Independent claims3
129 paragraphs in 6 sections, as filed
PRIORITY INFORMATION
0001The present application claims priority to U.S. Provisional Patent Application No. 60/703,812, filed Jul. 29, 2005, and U.S. Provisional Patent Application No. 60/764,748, filed Feb. 3, 2006. The entire contents of both provisional applications are incorporated herein by reference in their entireties.
BACKGROUND INFORMATION
0002The Internet Protocol Multimedia Subsystem (IMS) provides mobile and fixed multimedia services. The aim of IMS is not only to provide new services, but all the services, current and future, that the Internet provides. In this way, IMS gives network operators and service providers the ability to control and charge for each service. In addition, users are given the ability to execute services from their home networks, as well as when the users are roaming.
BRIEF DESCRIPTION OF THE DRAWINGS
0003The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings.
0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary system in which systems and methods, consistent with principles of the invention, may be implemented;
0005<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary configuration of the break-in gateway control function (BIGCF) of <figref idref="DRAWINGS">FIG. 1</figref>;
0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary process performed by the BIGCF of <figref idref="DRAWINGS">FIG. 1</figref>;
0007<figref idref="DRAWINGS">FIGS. 4A-4C</figref> illustrate the processing of <figref idref="DRAWINGS">FIG. 3</figref> in additional detail; and
0008<figref idref="DRAWINGS">FIGS. 5-12</figref> illustrate examples of the processing described in FIGS. <b>3</b> and <b>4</b>A-<b>4</b>C.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
0009The following detailed description of implementations consistent with principles of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents.
0010Implementations consistent with principles of the invention relate to routing traffic in relation to an Internet Protocol (IP) Multimedia Subsystem (IMS) (also referred to as an “IMS core” or “IMS platform”). The IMS core may be used for routing calls/data sessions from various originations towards various destinations with possible invocation of value-added service during processing and routing determination. Calls not involving IMS subscriber endpoints or IMS-based applications may bypass the IMS core for operational efficiency (i.e., latency).
0011It will be appreciated that the telephony terminology that is used herein covers the United States based PSTN structure. Implementations consistent with principles of the invention are not so limited. For example, implementations consistent with principles of the invention are equally applicable to other communication networks.
Exemplary System
0012<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary system <b>100</b> in which systems and methods, consistent with principles of the invention, may be implemented. As illustrated, system <b>100</b> may include a serving call session control function (S-CSCF) <b>102</b>, an interrogating call session control function (I-CSCF) <b>104</b>, a proxy call session control function (P-CSCF) <b>106</b>, a home subscriber server (HSS) <b>108</b>, a subscription location function (SLF) <b>110</b>, two media gateway (MOW) functions <b>112</b>, two media gateway control functions (MGCFs) <b>114</b>, a shared local gateway (SLG) <b>116</b>, a network gateway (NGW) <b>118</b>, a breakout gateway control function (BGCF) <b>120</b>, a break in gateway control function (BIGCF) <b>122</b>, a multimedia resource function (MRF) <b>124</b> that may include a multimedia resource function controller (MRFC) <b>126</b>, a multimedia resource function processor (MRFP) <b>128</b>, and a media resource broker (MRB) <b>130</b>, one or more application servers <b>132</b>, Services Creation Environment (SCE) logic <b>134</b>, a central office exchange service (CENTREX) <b>136</b>, a unified messaging service (UM) <b>138</b>, a carrier application service (AS) <b>140</b>, a group list management server (GLMS) <b>142</b>, a presence service <b>144</b>, a telephone number mapping (ENUM) server <b>146</b>, an access session border controller (A-SBC) <b>148</b>, an internetworking session border controller (I-SBC) <b>150</b>, a policy engine <b>152</b>, a policy decision function (PDF) <b>154</b>, a resource management function (RM) <b>156</b>, a charging function (CF) <b>158</b>, a charging data function (CDF) <b>160</b>, a charging gateway function (CGF) <b>162</b>, and a generic user profile (GUP) <b>164</b>. Although not specifically depicted in <figref idref="DRAWINGS">FIG. 1</figref>, the IMS core may include, for example, S-CSCF <b>102</b>, I-CSCF <b>104</b>, P-CSCF <b>106</b>, and HSS <b>108</b>. The number of components illustrated in <figref idref="DRAWINGS">FIG. 1</figref> is provided for simplicity. In practice, a typical system could include more or fewer components than illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. Moreover, it will be appreciated that the IMS standards are continually evolving. Implementations described herein are equally applicable to current and future IMS standards.
0013A. Call Session Control Components
0014S-CSCF <b>102</b>, I-CSCF <b>104</b>, and P-CSCF <b>106</b> may be considered call session control components in system <b>100</b>. The call control components may be responsible for parsing a session (e.g., a session initiation protocol (SIP) session) and applying logic (e.g., business logic, service logic, operational logic, etc.) on a per event basis. The outcome of the session control may be to route an event to the appropriate components and/or append SIP headers and values.
0015S-CSCF <b>102</b> may be viewed as the brain of the IMS core. S-CSCF <b>102</b> may perform session control and registration services for the users of the IMS core. S-CSCF <b>102</b> may receive a user profile from HSS <b>108</b> and route sessions requested by an IMS user (also called an “IMS subscriber” or “subscriber”). Additionally, S-CSCF <b>102</b> may perform user authentication based on information from HSS <b>108</b>.
0016In some implementations, S-CSCF <b>102</b> may include a Service Capability Interaction Manager (SCIM) and Resource Management (RM) functions. The SCIM may be responsible for orchestrating the offerings of one or more application services across various service enabling technologies and platforms to produce valued services for IMS users. The RM may be responsible for executing business rules and service level agreements (SLAs) by allocating the appropriate resources.
0017I-CSCF <b>104</b> may act as the main point of contact for connections to subscribers served by other IP networks. I-CSCF <b>104</b> may be located at the edge of the IMS core. I-CSCF <b>104</b> may receive SIP messages and identify the next hops for the SIP messages. To achieve this, I-CSCF <b>104</b> may query HSS <b>108</b> for the location (e.g., an address) of the appropriate S-CSCF to which a particular SIP message is to be forwarded.
0018P-CSCF <b>106</b> may act as the main point of contact for connections to subscribers of the local IMS. As such, P-CSCF <b>106</b> may validate requests, forward the requests to selected destinations, and process and forward the responses. P-CSCF <b>106</b> may generate chargeable events and send information relating to the chargeable events to CF <b>158</b>. Additionally, P-CSCF <b>106</b> may interact with PDF <b>154</b> to grant, reject, or downgrade a session request based on platform resources and quality of service (QoS) measurements.
0019HSS <b>108</b> may include one or more servers that act as the central repository for user-related information. HSS <b>108</b> may contain user-related subscription information for handling multimedia sessions. Some of the information contained in HSS <b>108</b> may include information identifying the location of a particular S-CSCF <b>102</b> for a particular user. As indicated above, the location of a particular S-CSCF <b>102</b> may be conveyed to I-CSCF <b>104</b> upon receiving a query from a network element. HSS <b>108</b> may also include user profile information that contains service trigger points and information identifying the corresponding resources (e.g., applications, media, services, etc.) that offer the services. The user profile information may be forwarded to S-CSCF <b>102</b> for session control and service treatment. Moreover, HSS <b>108</b> may provide and receive updates directly from application servers <b>132</b>.
0020SLF <b>110</b> may include one or more databases that contain service location information for subscribers. SLF <b>110</b> may receive a query, containing identification information for a subscriber, from I-CSCF <b>104</b> and return, based on the subscriber identification information, information identifying an HSS <b>108</b> that serves the subscriber.
0021B. Gateways and Gateway Control Functions
0022System <b>100</b> may include various components that bridge the IMS core to external networks, such as a public switched telephone network (PSTN), the Internet, etc. These components, which may include MGW function <b>112</b>, MGCF <b>114</b>, SLG <b>116</b>, NGW <b>118</b>, BGCF <b>120</b>, and BIGCF <b>122</b>, may perform protocol conversion and event routing to or from the IMS core.
0023MGW function <b>112</b> may connect PSTN networks and the IMS core. In one implementation, MGW function <b>112</b> may terminate bearer channels from a PSTN network and media steams 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), execute the conversion between these terminations, and perform transcoding and signal processing. In addition, MGW function <b>112</b> may provide tones and announcements to Circuit Switched (CS) users. In one implementation consistent with principles of the invention, MGW function <b>112</b> may operate under the control of MGCF <b>114</b>.
0024MGCF <b>114</b> may be part of the gateway infrastructure that enables communication between the IMS core and PSTN networks. MGCF <b>114</b> may perform protocol conversion between the Integrated Services Digital Network (ISDN) User Part (ISUP) or Primary Rate Interface (PRI) and SIP protocols before forwarding a session to the IMS core. In similar fashion, IMS-originated sessions directed towards PSTN users may traverse MGCF <b>114</b>. MGCF <b>114</b> may control media channels in MGW <b>112</b>. In addition, MGCF <b>114</b> may report account information to CF <b>158</b>.
0025SLG <b>116</b> may include an MGCF <b>114</b> and a set of associated MGW <b>112</b> entities within the same physical entity. SLG <b>116</b> may connect the IMS core to the local exchange layer of the PSTN. In one implementation, the interfaces between SLG <b>116</b> and the local exchange networks may include DS0 or Digital Signal 1 (DS1)-based Non-Facilities Associated Signaling (NFAS) PRIs.
0026NGW <b>118</b> may include an MGCF <b>114</b> and a set of associated MGW <b>112</b> entities which physically reside in a separate physical entities. NGW <b>118</b> may connect the IMS core to the Long Distance layer of the PSTN. In one implementation, the interfaces between MGCF <b>114</b> of NGW <b>118</b> and the Long Distance networks may include DS0 or DS1-based signaling system 7 (SS7) interfaces and the interfaces between MGW <b>112</b> of NGW <b>118</b> and the Long Distance networks may include DS1-bearer channels.
0027BGCF <b>120</b> may connect IMS-initiated calls to Circuit Switch (CS) customers (e.g., an IMS user calling a telephone number in the PSTN). BGCF <b>120</b> may, based on a routing policy, select an appropriate network in which the connection is to be made or may select the appropriate MGCF <b>114</b> to the other network.
0028BIGCF <b>122</b> may correspond to an ingress point that handles incoming calls from PSTN gateways (e.g., NGW <b>118</b>, SLG <b>116</b>, I-SBC <b>150</b>), wholesale gateways, other IP-based carriers (e.g., based on Voice over Internet Protocol (VoIP) peering agreements), Emergency Services Peering Points, etc. BIGCF <b>122</b> may route calls from and to non-IMS subscribers. BIGCF <b>122</b> may route calls to the IMS core, when the calls are destined for IMS subscribers or when IMS applications are invoked, or may bypass the IMS core elements (P-CSCF <b>106</b>, I-CSCF <b>104</b>, S-CSCF <b>102</b>, HSS <b>108</b>, etc.) when calls are destined for non-IMS subscribers and no IMS applications are invoked by the calling party or called party. BIGCF <b>122</b> may route calls to PSTN-based termination points to BGCF <b>120</b> and route calls to IP-based termination points (e.g., a wholesale termination point, IP-based carriers, etc.) directly to I-SBCs <b>150</b> associated with the IP-based termination points. BIGCF <b>122</b> may include static routing policies to route emergency calls to BGCF <b>120</b>. BIGCF <b>120</b> may also support static routing policies to route non-emergency calls from certain originations (e.g., a wholesale gateway requiring prepaid authorization for non-emergency calls) to pre-paid service controllers. If calls are either from and/or to IMS subscribers or IMS applications (or services) are invoked, BIGCF <b>122</b> may route the calls to the IMS core using I-CSCF <b>104</b> to invoke calling and/or called party features.
0029BIGCF <b>122</b> may include a group of configuration data. For example, BIGCF <b>122</b> may maintain a list of served hosts. If the request uniform resource indicator (R-URI) domain in the incoming request does not identify one of the served hosts, BIGCF <b>122</b> may either proxy 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) <b>403</b> response (or other type of message), unless the call is an emergency call. In this way, BIGCF <b>122</b> may reject calls destined for unknown entities.
0030BIGCF <b>122</b> may also include a list of emergency prefixes on a per country basis. For example, BIGCF <b>122</b> may store the prefix 911 for the United States. BIGCF <b>122</b> may store a list of non-geographic numbers per country of origin (e.g., 800, 411, etc.). Via this list, BIGCF <b>122</b> may route calls directly for PSTN breakout.
0031BIGCF <b>122</b> may further store a list of originating hosts (e.g., gateway uniform resource locators (URLs)) from which calls may be expected. If a call is not from one of the hosts in the list of origination hosts (either in the second topmost via or first via), BIGCF <b>122</b> may reject the request. The originating host based data may include a number of data elements. For example, the data elements may include a gateway IP address of one or more hostnames. The originating hosts may point to prefix/suffix information to normalize the calling party number. For example, a wholesale gateway origination may have a rule indicating that if 7 digits are given in the calling party number, then prefix the calling party number with +1732. The suffix information may indicate how many digits to consider after the suffix.
0032The originating hosts may identify a location of the calling party identity indicators. For example, the originating hosts may identify from which header in a SIP INVITE message to retrieve the calling party information.
0033The data elements may also include the country or location of the gateway. This location may be used by BIGCF <b>122</b> to normalize the called party number, based on the country of origination of the call. The location of the gateway may also be used by BIGCF <b>122</b> to identify a location of a gateway to which an emergency call is to be routed.
0034The data elements may further include a list of blocked prefixes from each origination host. For example, 1900* may indicate that “1-900” calling is blocked from this gateway. The data elements may further include an outbound route for each origination host. For example, non-emergency calls from a given host may be routed to a configured host, such as a pre-paid service controller.
0035In addition to the above data, BIGCF <b>122</b> may be configured with the following data: a variable to either allow or reject processing of an INVITE where the request URI does not match one of the configured served hosts; an option per originating domain or IP address to accept or reject the request; an option to process certain SIP requests; a prefix per origination that is not allowed; static routing rules based on prefix matching; a server group pointing to a farm of ENUM servers; a server group pointing to a farm of I-CSCF servers for routing to the IMS core; a server group pointing to a farm of BGCF servers for bypassing the IMS core and routing directly to BGCF <b>120</b>; a server group pointing to a farm of Emergency Services Positioning Servers (which may be part of the U.S. emergency service network); an option to specify that certain message(s) are to be directed to an error log or an on-screen display; an option to place a gateway in service and place a gateway out-of-service in BIGCF <b>122</b>; country codes needed for number normalizations; number normalization rules (e.g., based on originating gateway); an option for enabling or disabling logging categories; an option for enabling or disabling alarms; and an option for enabling or disabling metrics.
0036In one implementation consistent with principles of the invention, BIGCF <b>122</b> may connect to I-CSCF <b>104</b>, SLG <b>116</b>, NGW <b>118</b>, and BGCF <b>120</b> via SIP interfaces. Additionally, BIGCF <b>122</b> may connect to ENUM <b>146</b> via a DNS protocol interface.
0037C. Media Resource Function (MRF)
0038The IMS core may provide shared multimedia services. Examples of multimedia services (or applications) include playing announcements, audio/video recording and playback, Interactive Voice Response (IVR), fax reception and transmission, Automatic Speech Recognition (ASR), Text-To-Speech (TTS) session, multimedia conferencing, customized ring back tones, Push-to-talk Over Cellular (PoC), video messaging, etc. MRF <b>124</b> may be part of the IMS core and may support services that use multimedia streams.
0039As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, MRF <b>124</b> may include MRFC <b>126</b>, MREP <b>128</b>, and MRB <b>130</b>. MRFC <b>126</b> and MRFP <b>128</b> are the IMS resources that provide support for bearer-related services (e.g., multi-party sessions, announcements to a user, bearer transcoding, etc.). MRFC <b>126</b> may provide bearer control-related services. MRFP <b>128</b> may provide user plane resources that may be requested and instructed by MRFC <b>126</b>. MRB <b>130</b> may provide a resource management function that is able to allow media resources to become common resources shared among multiple applications.
0040D. Application Servers
0041Application Servers (AS) <b>132</b> may include one or more servers that provide enhanced audio, video, messaging and data services within the application layer of system <b>100</b>. Application servers <b>132</b> may be accessible to the users of the IMS core and provide value added multimedia services to those users. Application servers <b>132</b> may submit charges to the IMS core for the services that application servers <b>132</b> provide to the IMS user community.
0042Two types of application servers <b>132</b> that may be used within system <b>100</b> may include micro applications and macro applications (or macro application services). Micro applications may be provided on a common services delivery platform through the use of SCE logic <b>134</b>. Micro applications may include a wide variety of enhanced multimedia services that need a rapid development and deployment cycle. Macro application services may include Hosted IP CENTREX (HIPC) <b>136</b>, Unified Messaging (UM) <b>138</b>, and Carrier Application Service <b>140</b>.
0043HIPC <b>136</b> may correspond to a type of Private Branch Exchange (PBX) service in which switching occurs at a local telephone office instead of at the company premises where the traditional PBX is located. In one implementation, HIPC <b>136</b> may be replaced by or supplemented with a SIP Voice Features server. Unified messaging <b>138</b> may allow users to be able to retrieve and send voice messages from a single interface, regardless of the technology (e.g., telephone, personal computer, etc.) and may provide other unified messaging services (e.g., fax deposit retrieval, voice to email, etc.). Carrier AS <b>140</b> may facilitate tool free call processing.
0044E. Services Creation Environment (SCE)
0045SCE logic <b>134</b> may provide a foundation for rapid development of next generation services. SCE <b>134</b> may support Java Specification Request (JSR) <b>116</b> SIP Servlet and a suite of externalized application programming interfaces (APIs) for developers to gain access to the IMS core. A single SCE <b>134</b> may support a number of macro application servers and may support the building of micro applications.
0046F. Services
0047The IMS core may support a number of different services, such as GLMS <b>142</b>, Presence <b>144</b>, and ENUM server <b>146</b>. GLMS <b>142</b> may include one or more services that allow for group list creation, management, and use across multiple applications within the IMS core. GLMS <b>142</b> may enforce access and visibility rules. Presence <b>144</b> may include one or more services that automate the task of aggregating both presence and availability information. Presence <b>144</b> may inform one user about the status of another user's availability and willingness to communicate. Presence servers <b>144</b> may use a Presence User Agent (PUA) to manage the presence of the IMS subscribers and handle presence subscription requests. For example, an application or an IMS subscriber may act as a watcher, which is an entity that subscribes to presence information provided by Presence Server <b>144</b>. ENUM server <b>146</b> may provide translation of E.164 to SIP URIs. BIGCF <b>122</b> and S-CSCF <b>102</b> may query ENUM server <b>146</b> to determine a next hop for a call. In some implementations consistent with principles of the invention, BIGCF <b>122</b> may execute ENUM queries for both calling and called number resolution.
0048G. Border Elements
0049The IMS core may include one or more Session Border Controllers (SBCs) that provide control of the boundary between different service provider networks, provide signaling protocol inter-working between the SIP-based IMS core and other service provider networks, control the transport boundary between service provider networks, and provide usage metering and Quality of Service (QoS) measurements for media flows. Two types of SBCs that may be associated with the IMS core are the Access Session Border Controller (A-SBC) <b>148</b> and the I-SBC <b>150</b>.
0050A-SBC <b>148</b> may correspond to an ingress point to the IMS core for Customer Premises Equipment (CPE) traffic. A-SBC <b>148</b> may provide SIP aware firewall capabilities that support network address translation (NAT), prevent denial of service (DoS) attacks, and execute other security enforcement features. A-SBC <b>148</b> may be the first SIP events normalization point prior to the IMS core. In one implementation, A-SBC <b>148</b> may be replaced by or supplemented with a border gateway function.
0051Internetworking Session Border Controller (I-SBC) <b>150</b> may serve as a connection point between the IMS core and wholesale gateways and also between the IMS core and IP peering VoIP carriers. I-SBC <b>150</b> may provide SIP normalization and Topology Hiding and Internetwork Gateway (THIG) services. In one implementation, I-SBC <b>150</b> may be replaced by or supplemented with a Border Gateway Function (BGF).
0052H. Policy
0053System <b>100</b> may include a number of policy components. For example, system <b>100</b> may, as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, include a policy engine <b>152</b>, a PDF <b>154</b>, and a RM <b>156</b>. Policy engine <b>152</b> may include one or more rule-based engines that govern subscriber access to the IMS core, subscriber access to resources, and routing decisions for several different types of event requests made within the IMS core. In one implementation, policy engine <b>152</b> may provide decision logic to decision and policy points within the IMS core. PDF <b>154</b> may correspond to a Policy Decision Point (PDP) for service-based local policy control. PDF <b>154</b> may make policy decisions based on session and media related information. PDF <b>154</b> may exchange this decision information with another IMS element (such as A-SBC <b>148</b> or I-SBC <b>150</b>) to control the flow and characteristics of the communication link. RM <b>156</b> may be used to execute a policy at the component level. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, RM (Resource Management) <b>156</b> may be associated with, for example, S-CSCF <b>102</b>, BIGCF <b>122</b>, A-SBC <b>148</b>, and I-SBC <b>150</b>. In one implementation, RM <b>156</b> may store and execute the policy decisions that are relevant for the location at which RM <b>156</b> is associated.
0054I. Charging Function (CF)
0055CF <b>158</b> may include a unified system for affecting both offline charging and online charging. Offline charging is a process where charging information for network resource usage is collected concurrently with that resource usage. The charging information may be passed through a chain of CFs <b>158</b>. At the end of this process, Call Detail Record (CDR) files may be generated by the network, which may then be transferred to the network operator's billing domain for the purpose of subscriber billing processing, which may includes rating and rendering.
0056Online charging is a process where charging information can affect, in real time, the service rendered. Support of this capability may include direct interaction between the charging mechanism and the network's session control mechanism. An example of online charging includes pre-paid calling card usage.
0057CDF <b>160</b> may compile chargeable events gathered from IMS components into a single CDR for offline billing activities. CDF <b>160</b> may gather the chargeable events from a Charging Trigger Function (CTF) that may be associated with components of system <b>100</b> and, after creating the CDR, pass the billing data to the CGF <b>162</b>.
0058CGF <b>162</b> may act as a gateway between both the offline charging system, the online system, and an external post-processing system, such as a billing domain.
0059J. The Generic User Profile (GUP)
0060Information related to IMS subscribers may be in many formats, managed by many network elements and administrations. This complicates access to that data for users, network elements, and value-added service providers. Generic User Profile (GUP) <b>164</b> addresses this problem, providing a common conceptual description of subscriber data. A GUP server may provide a means to access the data described in GUP <b>164</b>.
Exemplary Configuration of BIGCF
0061<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary configuration of BIGCF <b>122</b>. As illustrated, BIGCF <b>122</b> may include a bus <b>210</b> processing logic <b>220</b> a memory <b>230</b> an input device <b>240</b>, an output device <b>250</b>, and a communication interface <b>260</b>. It will be appreciated that BIGCF <b>122</b> may include other components (not shown) that aid in receiving, transmitting, and/or processing data. Moreover, it will be appreciated that other configurations are possible.
0062Bus <b>210</b> may permit communication among the components of BIGCF <b>122</b>. Processing logic <b>220</b> may include any type of processor or microprocessor that interprets and executes instructions. In other implementations, processing logic <b>220</b> may be implemented as or include an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or the like. Memory <b>230</b> may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processing logic <b>220</b> a read only memory (ROM) or another type of static storage device that stores static information and instructions for the processing logic <b>220</b> and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.
0063Input device <b>240</b> may include a device that permits an operator to input information to BIGCF <b>122</b>, such as a keyboard, a keypad, a mouse, a pen, a microphone, one or more biometric mechanisms, and the like. Output device <b>250</b> may include a device that outputs information to the operator, such as a display, a speaker, etc.
0064Communication interface <b>260</b> may include any transceiver-like mechanism that enables BIGCF <b>122</b> to communicate with other devices and/or systems. For example, communication interface <b>260</b> may include mechanisms for communicating with other components within system <b>100</b>.
0065As will be described in detail below, BIGCF <b>122</b> may perform processing associated with routing calls from and to non-IMS subscribers. BIGCF <b>122</b> may perform these and other functions in response to processing logic <b>220</b> executing software instructions contained in a computer-readable medium, such as memory <b>230</b>. 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 <b>230</b> from another computer-readable medium or from another device via communication interface <b>260</b>. The software instructions contained in memory <b>230</b> may cause processing logic <b>220</b> 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 consistent with the principles of the invention are not limited to any specific combination of hardware circuitry and software.
Exemplary Process
0066<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart of an exemplary process for routing calls. The processing described in <figref idref="DRAWINGS">FIG. 3</figref> may be implemented by BIGCF <b>122</b>. Processing may begin with BIGCF <b>122</b> receiving a call request (act <b>310</b>). BIGCF <b>122</b> may receive the call request from, for example, a Class 3 (PSTN long distance) network, a Class 5 (PSTN local exchange) network, a wholesale subscriber, a prepaid application controller, or from other IP carriers.
0067BIGCF <b>122</b> may determine whether the call involves the IMS core (act <b>320</b>). To make this determination, BIGCF <b>122</b> may send a query to ENUM server <b>146</b> to determine if the calling party number is served by the IMS core. For example, if the calling party number is associated with an IMS profile that invokes an IMS application, BIGCF <b>122</b> may determine that the call involves the IMS core. BIGCF <b>122</b> may send a query to ENUM server <b>146</b> to determine if the called party number is served by the IMS core. For example, if the called party number is associated with an IMS subscriber or is associated with an IMS profile that invokes an IMS application, BIGCF <b>122</b> may determine that the call involves the IMS core. On the other hand, if the call does not involve an IMS application or is not destined for an IMS subscriber, BIGCF <b>122</b> may determine that the call does not involve the IMS core.
0068If BIGCF <b>122</b> determines that the call involves the IMS core, BIGCF <b>122</b> may route the call request to the IMS core to perform origination and/or termination IMS services (act <b>330</b>). BIGCG <b>122</b> may, for example, forward the call request to I-CSCF <b>104</b> of the IMS core for forwarding to the appropriate S-CSCF <b>102</b> for processing. S-CSCF <b>102</b> may invoke the appropriate IMS service(s) and/or forward the call request toward the appropriate IMS subscriber.
0069If, on the other hand, BIGCF <b>122</b> determines that the call does not involve the IMS core, BIGCF <b>122</b> may route the call request toward the appropriate destination, bypassing the IMS core (act <b>340</b>). BIGCF <b>122</b> may, for example, forward the call request to BGCF <b>120</b> for routing to an appropriate PSTN termination point or to an appropriate I-SBC <b>150</b> for routing to a wholesale or IP-based carrier termination point.
0070<figref idref="DRAWINGS">FIGS. 4A-4C</figref> are flowcharts of an exemplary process for routing calls. The processing described in <figref idref="DRAWINGS">FIGS. 4A-4C</figref> may be performed by BIGCF <b>122</b>. Processing may begin with BIGCF <b>122</b> determining whether a received call request is associated with a served domain (act <b>402</b>). To make this determination, BIGCF <b>122</b> may look up the domain portion of the request URI in a list of domains served by the IMS core. If the domain is not on the list, BIGCF <b>122</b> may route the call externally to the address resolved by the DNS-SRV (acts <b>404</b>, <b>406</b>, <b>408</b>), unless the call is determined to be an emergency call. BIGCF <b>122</b> may reject the call instead of routing externally, in the case of no match by sending a SIP <b>403</b> response or another type of response (acts <b>404</b>, <b>410</b>, <b>412</b>).
0071If the call request is associated with a served domain, BIGCF <b>122</b> may determine if the originating host is known (act <b>414</b>). For example, BIGCF <b>122</b> may compare the originating host to a list of originating hosts. If the originating host does not match a host in the list of originating hosts, BIGCF <b>122</b> may reject the call by sending a SIP <b>403</b> response or another type of response (acts <b>410</b>, <b>412</b>).
0072BIGCF <b>122</b> may analyze the user portion of the Request URI and if it is a numeric string, BIGCF <b>122</b> may look up this numeric string in a list of emergency numbers for a country, which is associated with an originating host (act <b>414</b> and act <b>416</b>, <figref idref="DRAWINGS">FIG. 4B</figref>). BIGCF <b>122</b> may route emergency calls to BGCF <b>120</b> bypassing the IMS core (act <b>416</b>). When the call is determined to be an emergency call, BIGCF <b>122</b> may insert an emergency call indicator.
0073For non-emergency calls, BIGCF <b>122</b> may apply static routing rules based on the originating hosts (act <b>418</b>). For example, regardless of the prefix, BIGCF <b>122</b> may route calls from a given host to a configured address. For example, BIGCF <b>122</b> may route calls from a certain gateway to a pre-paid service controller (act <b>420</b>). BIGCF <b>122</b> may also block calls from certain originations. For example, BIGCF <b>122</b> may block non-emergency calls from an Emergency Services Peering Point.
0074In one implementation, BIGCF <b>122</b> may support a routing policy where BIGCF <b>122</b> routes a called number matching a prefix in a list of prefixes directly to BGCF <b>120</b> (act <b>418</b>). This list of prefixes (e.g., non-geographic numbers) may be specific to a country, and may be configurable per originating host. As an example, if the IMS does not provide the associated freephone service, BIGCF <b>122</b> may route “1-800” calls directly to BGCF <b>120</b>.
0075After applying static routing rules based on prefix, origination, or a combination of both (act <b>418</b>), BIGCF <b>122</b> may apply call post screening processing based on configured rules on the originating party domain or IP address coupled with the dialed digits (called party identity) (act <b>422</b>, <figref idref="DRAWINGS">FIG. 4C</figref>). As one example, a rule may cause BIGCF <b>122</b> to reject any call if the identified prefix per originating domain is configured to be blocked.
0076When the call is not routed through a static rule, BIGCF <b>122</b> may perform calling party number (CgPN) normalization based on the entity that originated the call (act <b>424</b>, <figref idref="DRAWINGS">FIG. 4B</figref>). In this situation, normalization rules may be configured corresponding to the originating gateways. In some situations, the normalization may not result in an E.164 format (e.g., if the calling party identity is not normalizable or specific rules per originating gateways are not available).
0077BIGCF <b>122</b> may normalize the called party number (CdPN) (e.g., adding or stripping digits, adding “+”, etc.) based on rules for the country code from the calling party number and the dialed digits (act <b>424</b>). For example, if the calling party is in the United States and the calling party number has 10 digits, the prefix “+1” may be added. In some situations, an E.164 format may not be achieved if the called party identity is not normalizable.
0078If BIGCF <b>122</b> successfully normalizes the called party number (act <b>424</b>), BIGCF <b>122</b> may put the normalized number in a Request URI for ENUM <b>146</b> resolution and may save the originally dialed digits for possible eventual consumption by BGCF <b>120</b>. In one implementation consistent with principles of the invention, BIGCF <b>122</b> may save the originally dialed digits, from the received request URI, in the History-Info header of the request.
0079BIGCF <b>122</b> may select an outbound route (e.g., a route to I-CSCF <b>104</b>, BGCF <b>120</b>, or I-SBC <b>150</b>), in cases where the calling and/or called party numbers are not in E.164 format (act <b>426</b>). Table 1 provides possible route selections that may be performed by BIGCF <b>122</b>.
0080<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>BIGCF Routing For Non-E.164 Calling/Called Party Identities</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="161pt" align="left" /><tbody valign="top"><row><entry>Calling</entry><entry /><entry /></row><row><entry>Party</entry><entry>Called Party</entry><entry>Actions</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>E.164</entry><entry>E.164</entry><entry>Route based on URIs obtained via Infrastructure</entry></row><row><entry /><entry /><entry>ENUM queries (act 428).</entry></row><row><entry>E.164</entry><entry>Non-</entry><entry>1. Route to I-CSCF 104 if calling party lookup in</entry></row><row><entry /><entry>Normalizable into</entry><entry>infrastructure ENUM query results in a SIP URI</entry></row><row><entry /><entry>E.164</entry><entry>pointing to I-CSCF 104 (i.e., the IMS core), with</entry></row><row><entry /><entry /><entry>Route header: <sip:icscf address;mode=orig;lr>, to</entry></row><row><entry /><entry /><entry>indicate I-CSCF 104 to route based on origination</entry></row><row><entry /><entry /><entry>party to S-CSCF 102.</entry></row><row><entry /><entry /><entry>2. Route to I-CSCF 104. R-URI: called party (no</entry></row><row><entry /><entry /><entry>change)</entry></row><row><entry /><entry /><entry>Route Header: none (routing for terminating services</entry></row><row><entry /><entry /><entry>only)</entry></row><row><entry /><entry /><entry>History-Info: none (because R-URI is unchanged)</entry></row><row><entry /><entry /><entry>P-Asserted-Identity: Calling Party (E.164)</entry></row><row><entry /><entry /><entry>3. If the called party is associated with a non-</entry></row><row><entry /><entry /><entry>geographic prefix matching a prefix in a list of</entry></row><row><entry /><entry /><entry>prefixes associated with the call's origination, as</entry></row><row><entry /><entry /><entry>described above, BIGCF 122 may route the call to</entry></row><row><entry /><entry /><entry>BGCF 120, with no change in the R-URI, and no</entry></row><row><entry /><entry /><entry>Route and History-Info required.</entry></row><row><entry>E.164</entry><entry>Name</entry><entry>1. Route to I-CSCF 104.</entry></row><row><entry /><entry>(alphanumeric</entry><entry>R-URI: called party (no change)</entry></row><row><entry /><entry>characters in the</entry><entry>Route Header: none (routing for terminating services</entry></row><row><entry /><entry>user portion of R-</entry><entry>only)</entry></row><row><entry /><entry>URI)</entry><entry>History-Info: none (because R-URI is unchanged)</entry></row><row><entry /><entry /><entry>P-Asserted-Identity: Calling Party (E.164)</entry></row><row><entry>Non-E.164</entry><entry>E.164</entry><entry>Perform ENUM lookup for called party only, using</entry></row><row><entry /><entry /><entry>configured top-level domain for infrastructure ENUM</entry></row><row><entry /><entry /><entry>146. If response SIP URI from ENUM points to:</entry></row><row><entry /><entry /><entry>1. I-CSCF 104: route to IMS core, with R-URI: SIP</entry></row><row><entry /><entry /><entry>URI from ENUM, History-Info: original dialed</entry></row><row><entry /><entry /><entry>digits, with no route header</entry></row><row><entry /><entry /><entry>2. Wholesale/VoIP Peer: route to associated I-SBC</entry></row><row><entry /><entry /><entry>150 (as described further below), with R-URI:</entry></row><row><entry /><entry /><entry>SIP URI from ENUM, and with a Route header</entry></row><row><entry /><entry /><entry>pointing to I-SBC (as a single outbound route).</entry></row><row><entry /><entry /><entry>No History-Info is required.</entry></row><row><entry /><entry /><entry>3. NXDOMAIN: E.164 lookup returned no result.</entry></row><row><entry /><entry /><entry>Perform User ENUM query using configured</entry></row><row><entry /><entry /><entry>domain per originating address (act 430, FIG. 4C).</entry></row><row><entry /><entry /><entry>If there is any SIP URI returned from this query,</entry></row><row><entry /><entry /><entry>BIGCF 122 may directly route the call to the</entry></row><row><entry /><entry /><entry>address returned in the host part of the SIP URI.</entry></row><row><entry /><entry /><entry>In case of no response, BIGCF 122 may perform</entry></row><row><entry /><entry /><entry>one more ENUM query using top-level e164.arpa</entry></row><row><entry /><entry /><entry>domain, and route the call to the address returned</entry></row><row><entry /><entry /><entry>in SIP URI from ENUM. If this also does not</entry></row><row><entry /><entry /><entry>return a response, then:</entry></row><row><entry /><entry /><entry>Route to BGCF 120 for a possible PSTN</entry></row><row><entry /><entry /><entry>breakout, with R-URI: E.164 number, History-</entry></row><row><entry /><entry /><entry>Info: original dialed digits (if the called party</entry></row><row><entry /><entry /><entry>number has been normalized into E.164).</entry></row><row><entry /><entry /><entry>4. VOID: called party number out of service, reject</entry></row><row><entry /><entry /><entry>the call.</entry></row><row><entry>Non-E.164</entry><entry>Non-E.164</entry><entry>Route the call to I-CSCF 104 for possible terminating</entry></row><row><entry /><entry /><entry>feature invocation.</entry></row><row><entry>Non-E.164</entry><entry>Name</entry><entry>Route the call to I-CSCF 104 for possible terminating</entry></row><row><entry /><entry>(alphanumeric</entry><entry>feature invocation.</entry></row><row><entry /><entry>string)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0081Assume that BIGCF <b>122</b> receives the call request from SLG <b>116</b>, NGW <b>118</b>, or I-SBC <b>150</b>. BIGCF <b>122</b> may generate two DNS Naming Authority Pointer (NAPTR) queries towards ENUM <b>146</b> if the called and calling party numbers are in E.164 format (acts <b>424</b>, <b>428</b>, <figref idref="DRAWINGS">FIG. 4B</figref>). Table 2 provides an exemplary list of queries and possible responses to those queries. BIGCF <b>122</b> may maintain a routing table to identify an I-SBC <b>150</b> to which the call is to be forwarded based on the host part of the SIP URIs returned from ENUM <b>146</b>. The host part may identify the wholesale or VoIP peer gateway. In case of IMS core terminations, the returned ENUM response may identify an I-CSCF <b>104</b> to which the call is to be forwarded.
0082<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ENUM Queries</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="98pt" align="left" /><colspec colname="3" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>DNS NAPTR Query at</entry><entry /></row><row><entry>Query</entry><entry>ENUM</entry><entry>Query Response</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>A</entry><entry>CgPn.<configured</entry><entry>1. SIP URI pointing to I-CSCF 104.</entry></row><row><entry /><entry>infrastructure ENUM top</entry><entry>sip:<number>@icscf1.us.Verizon.com.</entry></row><row><entry /><entry>level domain></entry><entry>2. SIP URI pointing to VoIP wholesaler</entry></row><row><entry /><entry>e.g.,</entry><entry>interconnect gateway.</entry></row><row><entry /><entry>4.2.3.1.8.4.5.2.7.9.1.foo.bar</entry><entry>sip:<number>@gw1.wholesaler.com.</entry></row><row><entry>B</entry><entry>CdPn.<configured</entry><entry>3. SIP URI pointing to VoIP peering partner</entry></row><row><entry /><entry>infrastructure ENUM top</entry><entry>interconnect gateway.</entry></row><row><entry /><entry>level domain></entry><entry>sip:<number>@gw1.voippeer.com.</entry></row><row><entry /><entry>e.g.,</entry><entry>4. NXDOMAIN: This response means that no</entry></row><row><entry /><entry>3.2.3.1.5.6.3.2.7.9.1.foo.bar</entry><entry>translation information was found for the</entry></row><row><entry /><entry /><entry>specified number.</entry></row><row><entry /><entry /><entry>5. VOID: This indicates that the specified</entry></row><row><entry /><entry /><entry>number is out of service.</entry></row><row><entry>User</entry><entry>CdPn.e164.arpa</entry><entry>1. SIP URI pointing to any IP termination.</entry></row><row><entry>ENUM</entry><entry>e.g.,</entry><entry>2. NXDOMAIN: no record found.</entry></row><row><entry>Query</entry><entry>3.2.3.1.5.6.3.2.7.9.1.e164.arpa</entry><entry>3. VOID: number out of service.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0083BIGCF <b>122</b> may use the above responses from the two NAPTR queries to route calls to the IMS core (e.g., towards I-CSCF <b>104</b>) or bypassing the IMS core (I-SBC <b>150</b>). Table 3 below describes how a call is routed at BIGCF <b>122</b>, based on the responses received from ENUM server <b>146</b> to the above two queries.
0084If no records exist for the NAPTR queries, BIGCF <b>122</b> may query the user ENUM. If there is a SIP URI returned from this query, BIGCF <b>122</b> may directly route the call to the address indicated in the host part of the SIP UPI. If this does not return a valid URI, then BIGCF <b>122</b> may route the call to BGCF <b>120</b> (act <b>438</b>).
0085<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ENUM Query Responses Affecting Routing at BIGCF</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>Called Party</entry><entry /></row><row><entry>Calling Party</entry><entry>ENUM</entry></row><row><entry>ENUM Response</entry><entry>Response</entry><entry>Actions</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>n/a</entry><entry>VOID</entry><entry>Reject the call. Called number is out of service.</entry></row><row><entry>NXDOMAIN OR</entry><entry>SIP URI</entry><entry>Route to I-CSCF 104. R-URI: SIP URI from ENUM</entry></row><row><entry>VOID</entry><entry>Type: I-CSCF</entry><entry>146 for called party. Route header: none. History-Info</entry></row><row><entry>OR Wholesale or</entry><entry /><entry>header: original R-URI (used in ENUM query)</entry></row><row><entry>VoIP peer</entry></row><row><entry>gateway URI</entry></row><row><entry>NXDOMAIN</entry><entry>SIP URI</entry><entry>Route to I-SBC 150. R-URI: SIP URI from ENUM</entry></row><row><entry>OR VOID</entry><entry>Type:</entry><entry>146 for called party.</entry></row><row><entry>OR Wholesale or</entry><entry>Wholesale or</entry><entry>Route header: <I-SBC address;lr></entry></row><row><entry>VoIP peer</entry><entry>VoIP peer</entry><entry>History-Info: original R-URI (used in ENUM query)</entry></row><row><entry>gateway URI</entry><entry>gateway</entry></row><row><entry>NXDOMAIN</entry><entry>NXDOMAIN</entry><entry>Perform User ENUM query. If there is a SIP URI</entry></row><row><entry>OR VOID</entry><entry /><entry>returned from this query, BIGCF 122 may directly</entry></row><row><entry>OR Wholesale or</entry><entry /><entry>route the call to the address returned in the host part</entry></row><row><entry>VoIP peer</entry><entry /><entry>of the SIP URI. If this does not return a response,</entry></row><row><entry>gateway URI</entry><entry /><entry>then:</entry></row><row><entry /><entry /><entry>Route to BGCF 120 if not from SLG 116. All headers</entry></row><row><entry /><entry /><entry>unchanged. PSTN breakout.</entry></row><row><entry>SIP URI</entry><entry>NXDOMAIN</entry><entry>Route to I-CSCF 104. R-URI: SIP URI from ENUM</entry></row><row><entry>Type: I-CSCF</entry><entry>OR</entry><entry>146 for called party or no change if response from</entry></row><row><entry /><entry>SIP URI (any</entry><entry>ENUM is NXDOMAIN</entry></row><row><entry /><entry>type)</entry><entry>Route header: <sip:icscf address;mode=orig;lr>,</entry></row><row><entry /><entry /><entry>where icscf address is returned from ENUM query for</entry></row><row><entry /><entry /><entry>calling party.</entry></row><row><entry /><entry /><entry>History-Info: None or original dialed digits if RURI</entry></row><row><entry /><entry /><entry>is changed.</entry></row><row><entry /><entry /><entry>P-Asserted-Identity: SIP URI returned from ENUM</entry></row><row><entry /><entry /><entry>for calling party.</entry></row><row><entry>SIP URI</entry><entry>NXDOMAIN</entry><entry>Perform User ENUM query. If a SIP URI is returned</entry></row><row><entry>Type: wholesale</entry><entry /><entry>from this query, BIGCF 122 may directly route the</entry></row><row><entry /><entry /><entry>call to the address returned in the host part of the SIP</entry></row><row><entry /><entry /><entry>URI. If no response is returned, then:</entry></row><row><entry /><entry /><entry>Route to BGCF 120. R-URI: no change, Route: none,</entry></row><row><entry /><entry /><entry>History-Info: none. P-Asserted-Identity: SIP URI</entry></row><row><entry /><entry /><entry>returned from ENUM for calling party</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0086Once BIGCF <b>122</b> finds the route to be used for a call, BIGCF <b>122</b> may perform post route selection screening (act <b>422</b>, <figref idref="DRAWINGS">FIG. 4C</figref>) to check if the selected route is allowed. BIGCF <b>122</b> may route the call based on above queries to either I-CSCF <b>104</b> in the IMS core, towards BGCF <b>120</b>, or towards I-SBC <b>150</b> for IP-based termination points (act <b>432</b>, <figref idref="DRAWINGS">FIG. 4B</figref>; acts <b>434</b>, <b>436</b>, <b>438</b>, <figref idref="DRAWINGS">FIG. 4C</figref>).
EXAMPLES
0087The following examples illustrate the processing described above with respect to FIGS. <b>3</b> and <b>4</b>A-<b>4</b>C. <figref idref="DRAWINGS">FIG. 5</figref> illustrates exemplary processing for routing a call from a wholesale subscriber to a PSTN termination point. In this example, assume that neither the calling party (i.e., the wholesale subscriber) nor the called party (i.e., the PSNT termination point) invokes an IMS-based application.
0088As illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, the call may be received from the wholesale subscriber at a wholesale service provider (SP) gateway (GW) with which the wholesale subscriber is associated. The wholesale service provider gateway may forward the call to I-SBC <b>150</b> of system <b>100</b>.
0089Processing may begin with BIGCF <b>122</b> receiving the call from I-SBC <b>150</b> (act <b>510</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>520</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN (indicating that no record has been found in ENUM server <b>146</b>) or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>520</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0090In this example, BIGCF <b>122</b> may determine that the call is to be directed to a PSTN termination point and that no IMS application is to be invoked. BIGCF <b>122</b> may route the call to BGCF <b>120</b> (act <b>530</b>). BGCF <b>120</b> may identify a PSTN egress gateway for the call and route the call to the identified PSTN egress gateway (act <b>540</b>). The PSTN egress gateway may then route the call to the appropriate PSTN termination point. Therefore, in this example, BIGCF <b>122</b> may cause the call to bypass the IMS core.
0091<figref idref="DRAWINGS">FIG. 6</figref> illustrates exemplary processing for routing a call from a PSTN origination point to a wholesale subscriber. In this example, assume that neither the calling party (i.e., the PSTN origination point) nor the called party (i.e., the wholesale subscriber) invokes an IMS-based application.
0092As illustrated in <figref idref="DRAWINGS">FIG. 6</figref>, the call may be received from the calling party at a PSTN gateway (GW). The PSTN gateway may forward the call to BIGCF <b>122</b>.
0093Processing may begin with BIGCF <b>122</b> receiving the call from the PSTN gateway (act <b>610</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>620</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>620</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. It on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0094In this example, BIGCF <b>122</b> may determine that the call is to be directed to a wholesale service provider gateway and that no IMS application is to be invoked. BIGCF <b>122</b> may determine an egress point (e.g., I-SBC <b>150</b>) through which to access the wholesale service provider gateway identified in the ENUM response, and route the call via that I-SBC <b>150</b> (act <b>630</b>) to the wholesale service provider gateway. The wholesale service provider gateway may then route the call to the appropriate wholesale subscriber. Therefore, in this example, BIGCF <b>122</b> may cause the call to bypass the IMS core.
0095<figref idref="DRAWINGS">FIG. 7</figref> illustrates exemplary processing for routing a call from a PSTN origination point to a PSTN termination. In this example, assume that neither the calling party (i.e., the PSTN origination point) nor the called party (i.e., the PSTN termination point) invokes an IMS-based application.
0096As illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, the call may be received from the calling party at a PSTN gateway. The PSTN gateway may forward the call to BIGCF <b>122</b>.
0097Processing may begin with BIGCF <b>122</b> receiving the call from the PSTN gateway (act <b>710</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>720</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>720</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0098In this example, BIGCF <b>122</b> may determine that the call is to be directed to a PSTN termination point and that no IMS application is to be invoked. BIGCF <b>122</b> may route the call to BGCF <b>120</b> (act <b>730</b>). BGCF <b>120</b> may identify a PSTN egress gateway for the call (which may be the same PSTN gateway that received the call or a different PSTN gateway) and route the call to the identified PSTN egress gateway (act <b>740</b>). The PSTN egress gateway may then route the call to the appropriate PSTN termination point. Therefore, in this example, BIGCF <b>122</b> may cause the call to bypass the IMS core.
0099<figref idref="DRAWINGS">FIG. 8</figref> illustrates exemplary processing for routing a call from a PSTN origination point to an IMS user. As illustrated in <figref idref="DRAWINGS">FIG. 8</figref>, the call may be received from the calling party (i.e., the PSTN origination point) at a PSTN gateway. The PSTN gateway may forward the call to BIGCF <b>122</b>.
0100Processing may begin with BIGCF <b>122</b> receiving the call from the PSTN gateway (act <b>810</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>820</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>820</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0101In this example, BIGCF <b>122</b> may determine that the called party is served by the IMS core. Thus, the response from ENUM server <b>146</b> may include information for routing the call to I-CSCF <b>104</b> of the IMS core. BIGCF <b>122</b> may route the call to I-CSCF <b>104</b> (act <b>830</b>). I-CSCF <b>104</b> may route the call to the appropriate S-CSCF <b>102</b>, which may retrieve information relating to the called party (e.g., a profile from HSS <b>108</b> (not shown)). S-CSCF <b>102</b> may forward the call to the A-SBC <b>148</b> with which the IMS user is associated (act <b>840</b>). Therefore, in this example, BIGCF <b>122</b> may route the call through the IMS core.
0102<figref idref="DRAWINGS">FIG. 9</figref> illustrates exemplary processing for routing a call from a wholesale subscriber to an IMS subscriber. As illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, the call may be received from the wholesale subscriber at a wholesale service provider (SP) gateway (GW). The wholesale service provider gateway may forward the call to I-SBC <b>150</b> of system <b>100</b>.
0103Processing may begin with BIGCF <b>122</b> receiving the call from I-SBC <b>150</b> (act <b>910</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>920</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>920</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0104In this example, BIGCF <b>122</b> may determine that the called party is served by the IMS core. Thus, the response from ENUM server <b>146</b> may include information for routing the call to I-CSCF <b>104</b> of the IMS core. BIGCF <b>122</b> may route the call to I-CSCF <b>104</b> (act <b>930</b>). I-CSCF <b>104</b> may route the call to the appropriate S-CSCF <b>102</b>, which may retrieve information relating to the called party (e.g., a profile from HSS <b>108</b> (not shown)). S-CSCF <b>102</b> may forward the call to the A-SBC <b>148</b> with which the IMS user is associated (act <b>940</b>). Therefore, in this example, BIGCF <b>122</b> may route the call through the IMS core.
0105<figref idref="DRAWINGS">FIG. 10</figref> illustrates exemplary processing for routing a call from a wholesale subscriber to a PSTN termination point in another implementation consistent with principles of the invention. In this example, assume that either the calling party (i.e., the wholesale subscriber) and/or the called party (i.e., the PSTN termination point) invokes an IMS-based application.
0106As illustrated in <figref idref="DRAWINGS">FIG. 10</figref>, the call may be received from the wholesale subscriber at a wholesale service provider gateway. The wholesale service provider gateway may forward the call to I-SBC <b>150</b> of system <b>100</b>.
0107Processing may begin with BIGCF <b>122</b> receiving the call from I-SBC <b>150</b> (act <b>1010</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>1020</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. It on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>1020</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0108In this example, BIGCF <b>122</b> may determine that the call is to be directed to the IMS core. Thus, the response from ENUM server <b>146</b> may include information for routing the call to I-CSCF <b>104</b> of the IMS core. BIGCF <b>122</b> may route the call to I-CSCF <b>104</b> (act <b>1030</b>). I-CSCF <b>104</b> may route the call to S-CSCF <b>102</b>, which may perform the necessary application invocation. Since the call is directed to a PSTN termination point, S-CSCF <b>102</b> may query ENUM server <b>146</b> to map the called party number to a SIP URI (act <b>1040</b>). S-CSCF <b>102</b> may route the call with the SIP URI to BGCF <b>120</b> (act <b>1050</b>).
0109BGCF <b>120</b> may identify a PSTN egress gateway for the call and route the call to the identified PSTN egress gateway (act <b>1060</b>). The PSTN egress gateway may then route the call to the appropriate PSTN termination point. Therefore, in this example, BIGCF <b>122</b> may route the call through the IMS core for invoking one or more IMS applications for the call.
0110<figref idref="DRAWINGS">FIG. 11</figref> illustrates exemplary processing for routing a call from a PSTN origination to a wholesale subscriber. In this example, assume that either the calling party and/or the called party invokes an IMS-based application.
0111As illustrated in <figref idref="DRAWINGS">FIG. 11</figref>, the call may be received from the calling party at a PSTN gateway (GW). The PSTN gateway may forward the call to BIGCF <b>122</b>.
0112Processing may begin with BIGCF <b>122</b> receiving the call from the PSTN gateway (act <b>1110</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>1120</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>1120</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0113In this example, BIGCF <b>122</b> may determine that the call is to be directed to the IMS core. Thus, the response from ENUM server <b>146</b> may include information for routing the call to I-CSCF <b>104</b> of the IMS core. BIGCF <b>122</b> may route the call to I-CSCF <b>104</b> (act <b>1130</b>). I-CSCF <b>104</b> may route the call to S-CSCF <b>102</b>, which may perform the necessary application invocation. Since the call is directed to a wholesale subscriber, S-CSCF <b>102</b> may query ENUM server <b>146</b> to map the called party number to a SIP URI (act <b>1140</b>). S-CSCF <b>102</b> may route the call with the SIP URI to a wholesale gateway, via an I-SBC <b>150</b> associated with that gateway (act <b>1150</b>). In another implementation, S-CSCF <b>102</b> may use a static registration, in the case where an IMS application is invoked for the called party, to route the call to the wholesale subscriber.
0114The wholesale service provider gateway may then route the call to the appropriate wholesale subscriber. Therefore, in this example, BIGCF <b>122</b> may route the call through the IMS core for invoking one or more IMS applications for the call.
0115<figref idref="DRAWINGS">FIG. 12</figref> illustrates exemplary processing for routing a call from a PSTN origination point to a PSTN termination point. In this example, assume that either the calling party (i.e., the PSTN origination point) and/or the called party (i.e., the PSTN termination point) invokes an IMS-based application.
0116As illustrated in <figref idref="DRAWINGS">FIG. 12</figref>, the call may be received from the calling party at a PSTN gateway (GW). The PSTN gateway may forward the call to BIGCF <b>122</b>.
0117Processing may begin with BIGCF <b>122</b> receiving the call from the PSTN gateway (NGW or SLO) (act <b>1210</b>). In response to receiving the call, BIGCF <b>122</b> may query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the calling party number to determine whether the calling party is served by the IMS core (act <b>1220</b>). If the calling party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the calling party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code. BIGCF <b>122</b> may also query ENUM server <b>146</b> (e.g., using a NAPTR DNS query) based on the called party number to determine whether the called party is served by the IMS core (act <b>1220</b>). If the called party is served by the IMS core, the response from ENUM server <b>146</b> may include information identifying an I-CSCF <b>104</b> for the IMS core. If, on the other hand, the called party is not served by the IMS core, the response from ENUM server <b>146</b> may include a NXDOMAIN or similar response code.
0118In this example, BIGCF <b>122</b> may determine that the call is to be directed to the IMS core. Thus, the response from ENUM server <b>146</b> may include information for routing the call to I-CSCF <b>104</b> of the IMS core. BIGCF <b>122</b> may route the call to I-CSCF <b>104</b> (act <b>1230</b>). I-CSCF <b>104</b> may route the call to S-CSCF <b>102</b>, which may perform the necessary application invocation. Since the call is directed to a PSTN termination point, S-CSCF <b>102</b> may query ENUM server <b>146</b> to map the called party number to a SIP URI (act <b>1240</b>). S-CSCF <b>102</b> may route the call with the SIP URI to BGCF <b>120</b> (act <b>1250</b>).
0119BGCF <b>120</b> may identify a PSTN egress gateway (which may or may not be the same PSTN gateway that received the call and forwarded the call to BIGCF <b>122</b>) for the call and route the call to the identified PSTN egress gateway (act <b>1260</b>). The PSTN egress gateway may then route the call to the appropriate PSTN termination point. Therefore, in this example, BIGCF <b>122</b> may route the call through the IMS core for invoking one or more IMS applications for the call.
CONCLUSION
0120Implementations described herein provide a break in gateway control function that routes calls through an IMS core when needed. If a call involves an IMS subscriber or invokes an IMS application, the break in gateway control function may route the call through the IMS core. If on the other hand, a call does not involve an IMS subscriber or invoke an IMS application, the break in gateway control function may bypass the IMS core.
0121The foregoing description of exemplary implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, the call routing situations described above are provided for explanatory purposes only. Other call routing situations are possible that rely on the break in gateway control function. For example, calling routing from a wholesale subscriber/VoIP peering subscriber to a wholesale subscriber/VoIP peering subscriber may involve the break in gateway control function.
0122While series of acts have been described with respect to <figref idref="DRAWINGS">FIGS. 3-12</figref>, the order of the acts may be varied in other implementations consistent with the invention. Moreover, non-dependent acts may be implemented in parallel.
0123It will be apparent to one of ordinary skill in the art that aspects of the invention, as described above, 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 of the invention 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.
0124Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as an application specific integrated circuit, a field programmable gate array, a processor, or a microprocessor, software, or a combination of hardware and software.
0125Implementations consistent with principles of the invention are generally applicable to multimedia sessions implemented over an Internet Protocol infrastructure that uses E.164 numbers to identify endpoints. Neither the usage of terms (e.g., “call”) frequently associated with telephony, nor the historic association of E.164 numbers with such services, limits the scope or applicability of this invention.
0126No 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. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
Contents6
16 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US9143538B2 | Cited by | United States of America | Search report |
| US10609153B2 | Cited by | United States of America | Applicant |
| US2013215882A1 | Cited by | United States of America | Pre-grant |
| US2013021998A1 | Cited by | United States of America | Pre-grant |
| US9686326B2 | Cited by | United States of America | Applicant |
| US9094438B2 | Cited by | United States of America | Search report |
| US2018227371A1 | Cited by | United States of America | Search report |
| US2013010772A1 | Cited by | United States of America | Pre-grant |
| US9961148B2 | Cited by | United States of America | Applicant |
| US9160772B2 | Cited by | United States of America | Search report |
| US10348781B2 | Cited by | United States of America | Applicant |
| WO0174108A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0178328A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| US2003027569A1 | Cites | United States of America | Applicant |
| US2003046396A1 | Cites | United States of America | Applicant |
| WO2004008786A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| US2004068574A1 | Cites | United States of America | Applicant |
| US2004148416A1 | Cites | United States of America | Search report |
| US2004190498A1 | Cites | United States of America | Applicant |
| US2005014483A1 | Cites | United States of America | Applicant |
| US2005050194A1 | Cites | United States of America | Applicant |
| US2005050195A1 | Cites | United States of America | Applicant |
| US2005064883A1 | Cites | United States of America | Applicant |
| US2005177616A1 | Cites | United States of America | Applicant |
| US2005213606A1 | Cites | United States of America | Applicant |
| US2006104431A1 | Cites | United States of America | Applicant |
| US2006206504A1 | Cites | United States of America | Search report |
| US2006253538A1 | Cites | United States of America | Applicant |
| US2006270404A1 | Cites | United States of America | Applicant |
| US2007201452A1 | Cites | United States of America | Applicant |
| US5689553A | Cites | United States of America | Search report |
| US6578076B1 | Cites | United States of America | Applicant |
| US6701160B1 | Cites | United States of America | Applicant |
| US7079627B2 | Cites | United States of America | Search report |
| US7155248B2 | Cites | United States of America | Search report |
| US7209458B2 | Cites | United States of America | Applicant |
| US7606902B2 | Cites | United States of America | Applicant |
| US20030027569A1 | Cites | United States of America | Applicant |
| US20030046396A1 | Cites | United States of America | Applicant |
| US20040068574A1 | Cites | United States of America | Applicant |
| US20040148416A1 | Cites | United States of America | Search report |
| US20040190498A1 | Cites | United States of America | Applicant |
| US20050014483A1 | Cites | United States of America | Applicant |
| US20050050194A1 | Cites | United States of America | Applicant |
| US20050050195A1 | Cites | United States of America | Applicant |
| US20050064883A1 | Cites | United States of America | Applicant |
| US20050177616A1 | Cites | United States of America | Applicant |
| US20050213606A1 | Cites | United States of America | Applicant |
| US20060104431A1 | Cites | United States of America | Applicant |
| US20060206504A1 | Cites | United States of America | Search report |
| US20060253538A1 | Cites | United States of America | Applicant |
| US20060270404A1 | Cites | United States of America | Applicant |
| US20070201452A1 | Cites | United States of America | Applicant |
| WO0174108 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO0178328 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO2004008786 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Internet Protocol (IP) Based IP Multimedia Subsystem (IMS) Emergency Sessions; (Release 7),” 3GPP TR 23,867 V1.0.0, pp. 1-82, May 2005. | Non-patent | – | Applicant |
| “Digital Cellular Telecommunications System (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP Ts 23.228 Version 6.10.0 Release 6); ETSI TS 123 228,” pp. 1-182, Jun. 2005. | Non-patent | – | Applicant |
| "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Internet Protocol (IP) Based IP Multimedia Subsystem (IMS) Emergency Sessions; (Release 7)," 3GPP TR 23,867 V1.0.0, pp. 1-82, May 2005. | Non-patent | – | Applicant |
| "Digital Cellular Telecommunications System (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP Ts 23.228 Version 6.10.0 Release 6); ETSI TS 123 228," pp. 1-182, Jun. 2005. | Non-patent | – | Applicant |
50 members in 6 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 70381205 | United States of America | P | |
| 76474806 | United States of America | P |
Members50
| Document | Office | Kind | |
|---|---|---|---|
| US2007027975A1 | United States of America | A1 | |
| WO2007016447A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2007016448A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2007016472A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2007061397A1 | United States of America | A1 | |
| US2007071221A1 | United States of America | A1 | |
| US2007086582A1 | United States of America | A1 | |
| US2007088836A1 | United States of America | A1 | |
| WO2007016448A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2007016447A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1913485A2 | European Patent Office (EPO) | A2 | |
| WO2008067340A2 | World Intellectual Property Organization (WIPO) | A2 | |
| EP1932081A2 | European Patent Office (EPO) | A2 | |
| EP1932082A2 | European Patent Office (EPO) | A2 | |
| WO2008079630A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2008067340A3 | World Intellectual Property Organization (WIPO) | A3 | |
| CN101278272A | China | A | |
| CN101278273A | China | A | |
| EP1913485A4 | European Patent Office (EPO) | A4 | |
| WO2007016472A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2087435A2 | European Patent Office (EPO) | A2 | |
| CN101518015A | China | A | |
| EP1932082A4 | European Patent Office (EPO) | A4 | |
| CN101617302A | China | A | |
| HK1136655A | Hong Kong, China | A | |
| HK1136655A1 | Hong Kong, China | A1 | |
| US7792275B2 | United States of America | B2 | |
| EP1932081A4 | European Patent Office (EPO) | A4 | |
| US2010317334A1 | United States of America | A1 | |
| CN101278272B | China | B | |
| US7975037B2 | United States of America | B2 | |
| CN101278273B | China | B | |
| US2011231540A1 | United States of America | A1 | |
| US2012020350A1 | United States of America | A1 | |
| EP2087435A4 | European Patent Office (EPO) | A4 | |
| EP2448214A1 | European Patent Office (EPO) | A1 | |
| US8234388B2 | United States of America | B2 | |
| EP1913485B1 | European Patent Office (EPO) | B1 | |
| CN101617302B | China | B | |
| US2012237014A1 | United States of America | A1 | |
| ES2390471T3 | Spain | T3 | |
| US8325905B2 | United States of America | B2 | |
| EP1932082B1 | European Patent Office (EPO) | B1 | |
| US8635324B2 | United States of America | B2 | |
| US8644460B2 | United States of America | B2 | |
| US8737592B2 | United States of America | B2 | |
| US8798253B2This record | United States of America | B2 | |
| US8918526B2 | United States of America | B2 | |
| EP1932081B1 | European Patent Office (EPO) | B1 | |
| EP2087435B1 | European Patent Office (EPO) | B1 |
127 transactions on the USPTO file
Allowed after 3 non-final rejections, 2 final rejections, 1 RCE and 1 appeal.
- Non-final rejections
- 3
- Final rejections
- 2
- RCEs
- 1
- Appeals
- 1
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Response to Reasons for AllowanceREAS | REAS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Response to Reasons for AllowanceREAS | REAS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Reasons for AllowanceEX.R | EX.R | |
| Amendment/Argument after BPAI DecisionBD.A | BD.A | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail BPAI Decision on Appeal - Affirmed in PartMAPDP | MAPDP | |
| BPAI Decision - Examiner Affirmed in PartAPDP | APDP | |
| Email NotificationEML_NTR | EML_NTR | |
| Docketing Notice Mailed to AppellantAP_DK_M | AP_DK_M | |
| Assignment of Appeal NumberAPAS | APAS | |
| Appeal Awaiting BPAI DocketingAPWD | APWD | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Reply Brief Noted by ExaminerMRBNE | MRBNE | |
| Reply Brief Noted by ExaminerRBNE | RBNE | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Reply Brief FiledAPRB | APRB | |
| Exam. Ans. Review CompletePACC | PACC | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Examiner's AnswerMAPEA | MAPEA | |
| Examiner's Answer to Appeal BriefAPEA | APEA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Appeal Brief Review CompleteAPBR | APBR | |
| Appeal Brief FiledAP.B | AP.B | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Notice of Appeal FiledN/AP | N/AP | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Email NotificationEML_NTR | EML_NTR | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Mail Post CardPST_CRD | PST_CRD | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Reference capture on IDSRCAP | RCAP | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Date Forwarded to ExaminerFWDX | FWDX |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 8798253
- Application
- 11460750
Titles
- English
- Network routing
Patent term adjustment
- A delay
- +75 daysthe office missed an examination deadline
- B delay
- +575 dayspendency past three years
- C delay
- +1,089 daysinterference, secrecy order or appeal
- Applicant delay
- −142 days
- Net adjustment
- 1,597 days
Classification
- CPC, 16
- H04M7/123
- H04L41/06
- H04L41/5003
- H04L41/509
- H04L41/5096
- H04L43/0817
- H04L63/102
- H04M7/128
- H04Q3/0025
- H04Q3/0045
- H04L65/1016
- H04L65/1069
- H04L65/1096
- H04L61/4557
- H04L65/401
- H04L41/0894
- IPC, 2
- H04M3 00
- H04L41 0894