Network device and method for a general purpose central exchange

Abstract

The present disclosure generally relates to wireless communication systems, and more particularly to a network device and method for a universal central exchange (Centrex). The network device receives a short code dialed by a first user from a first user device to a second user device, from a second user device to a second user device, and of a first user device between / within circles. Furthermore, the network device determines whether the received short code is a SIP trunking code or an IP Centrex / Centrex code, and converts the received short code to an associated Uniform Resource Identifier (URI). Then, the network device performs E.164 Number to URI Mapping (ENUM) or Mobile Number Portability (MNP) to the URI, and sends a SIP INVITE request to invite a second user associated with the first user device to a session. Furthermore, the network device processes the call between the first user and the second user based on receiving the call by the second user.

Description

[Technical Field]

[0001] Reservation of Rights Portions of the disclosure of this patent document contain material that is subject to intellectual property rights, including, but not limited to, copyright, designs, trademarks, IC layout designs, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred to as the Owner). The Owner does not object to the reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights. All rights to such intellectual property rights are fully reserved by the Owner.

[0002] FIELD OF THE DISCLOSURE Embodiments of the present disclosure relate generally to wireless communication systems. More particularly, the present disclosure relates to network devices and methods for Universal Central exchange (Centrex). [Background technology]

[0003] The following discussion of the prior art is intended to provide background information related to the field of the present disclosure. This section may include some aspects of the prior art that may be relevant to various features of the present disclosure. However, it should be understood that this section is merely intended to enhance the reader's understanding of the present disclosure and is not intended to be an admission of prior art.

[0004] Generally, the Internet Protocol Multimedia Subsystem (IMS) may have three main layers, which may include a transport layer, a control layer, and a service / application layer. The IMS may support multiple application servers for telephony services within the service / application layer. IMS applications may provide specific services to end users. IMS end-user services may include multi-party gaming, video conferencing, messaging, community services, presence, content sharing, etc. Depending on the implementation, a telephony application server (TAS) may be required to be able to host one or more different applications. In the IMS, depending on the requirements and for different applications / services, there may be three types of TASs within the service / application layer: (a) a Session Initiation Protocol (SIP) application server, (b) an Open Service Access (OSA) application server, and (c) a CAMEL service environment. All of the above-mentioned servers may be combined into one unit, which may also be called a TAS. The IMS architecture may enable IMS service providers to deploy multiple application servers within the same domain. Different application servers can be deployed for different applications. TAS integrates voice, video, instant messaging, presence, mobility, conferencing, and collaboration across any network and any device. Central exchange (Centrex) or centralized user switch services divide users into basic user groups relative to the central office or carrier switch and provide various functions of the user-specific switch to the user groups while also providing some specific service features. The users' internal and external exchanges are aggregated at the central office or carrier switch.Traditional users such as those in the Public Switched Telephone Network (PSTN), Global System for Mobile Communications (GSM), and Code Division Multiple Access may be included in one group.

[0005] In one scenario, for example, consider an organization where some phones serve one location through an Internet Protocol Private Branch Exchange (IP PBX) and where Plain Old Telephone Service (POTS) phones serve another location through a legacy Primary Rate Interface (PRI) connectivity-based PBX. Furthermore, to upgrade to modern systems and technologies, the organization may need to replace the legacy PBX with an IP PBX, which would result in additional IP PBX migration costs. Furthermore, there may be no provision for short code dialing between IP PBX phones and PBX phones. Additionally, there may be no Centrex service for short code dialing between PBXs and IP PBXs or between Centrex and IP Centrex. Summary of the Invention [Problem to be solved by the invention]

[0006] Therefore, there is a need to arrive at a network device and method for providing a universal central exchange (Centrex) that addresses at least the above problems. [Means for solving the problem]

[0007] Some of the objectives of the present disclosure that at least one embodiment herein will satisfy are listed herein below.

[0008] In a general aspect, the present disclosure provides network devices and methods for a general purpose central exchange (Centrex).

[0009] In another aspect, the present disclosure provides a network device that is to be integrated into an operator's Internet Protocol Multimedia Subsystem (IMS) core network.

[0010] In another aspect, the present disclosure provides a generic Centrex service as a value-added service over any of the existing voice services: SIP Trunk, Centrex, IP Centrex, and Society Centrex.

[0011] In another aspect, the present disclosure enables universal Centrex services with abbreviated number dialing between Centrex / IP Centrex users and SIP trunking users, between SIP trunking users, and between inter / intra circle Centrex / IP Centrex users within the same city or across the country.

[0012] In yet another aspect, the present disclosure enables porting of plain old telephone service (POTS) telephones to IP without incurring the costs of a private branch exchange (PBX), and allows customers to enjoy the benefits of dialing between Internet Protocol (IP) PBXs and new universal Centrex users.

[0013] In another aspect, the present disclosure may support abbreviated number dialing between Centrex / IP Centrex to SIP trunking users and SIP trunking to SIP trunking users or inter-circle / intra-circle Centrex / IP Centrex users.

[0014] In another aspect, the present disclosure allows for private numbering patterns (2 / 3 / 4 / 5 / 6 digits) nationwide.

[0015] In another aspect, the present disclosure merges multiple SIP trunks with one pilot number (same location, same authorized signatory, same billing identity, etc.).

[0016] In another aspect, the present disclosure allows for existing setups as well as new setups under one Centrex group.

[0017] This section is provided to introduce, in a simplified form, certain objects and aspects of the present invention that are further described below in the Detailed Description. This Summary is not intended to identify key features or the scope of the claimed subject matter.

[0018] In one aspect, the present disclosure provides a network device for a universal central exchange (Centrex). The network device receives a short code dialed by a first user from at least one of a first user device to a second user device, a second user device to a second user device, and an inter-circle / intra-circle first user device. The second user device is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs). The network device further determines whether the received short code is at least one of a SIP trunking code or an IP Centrix / Centrex code. Based on the determination, the network device further translates the received short code into an associated Uniform Resource Identifier (URI) corresponding to at least one of the SIP trunking code or the IP Centrix / Centrex code. The short code corresponds to at least one of a fixed-line number and a mobile phone number. The network device then performs at least one of E.164 number to URI mapping (ENUM) and Mobile Number Portability (MNP). Furthermore, the network device sends a SIP INVITE request to invite a second user associated with at least one of the first user devices to a session. The SIP INVITE includes a URI address along with a domain name associated with the second user. Furthermore, the network device sends a Caller Ring Back Tone (CRBT) to the first user, while, upon receiving a SIP INVITE response from the second user, originates a call to the second user associated with at least one of the first user device and the second user device.Further, the network device processes a call between the first user and the second user based on making a call to the second user associated with at least one of the first user device and the second user device and then receiving a call by the second user.

[0019] In one embodiment, the short code is received from at least one of the first user device and the second user device via an Enterprise Session Border Controller (ESBC), a Proxy-Call Session Control Function (PCSCF), or a Serving-Call Session Control Function (SCSCF), and the ESBC forwards the traffic to an Internet Protocol Multimedia Subsystem (IMS) core network, which is a common IMS architecture deployed within an operator environment.

[0020] In one embodiment, at least one of the SIP trunking code or the IP centric / centrex code is determined based on an area code associated with the short code dialed by the first user.

[0021] In one embodiment, the call originates from an Enterprise Session Border Controller (ESBC), and the network device holds all number configurations associated with SIP trunks, Centrex / IP Centrex, and respective Closed User Group (CUG) definitions.

[0022] In one embodiment, the processor may merge multiple second user devices with one main number, where the main number is associated with the same location, the same authorized signatory, and the same billing identity.

[0023] In one embodiment, the processor may send a Credit-Control-Request (CCR) to an Online Charging Server (OCS) and receive a Credit-Control-Answer (CCA) from the OCS upon performing at least one of ENUM and MNP for the URI and after a SIP INVITE to a second user associated with at least one of the first user device and the second user device.

[0024] In one embodiment, upon receiving the CCA from the OCS, the processor may send a Location Information Request (LIR) via the SCSCF to an Interconnect Border Control Function (IBCF) associated with at least one of the first user device and the second user device of the first user, about the first user information, and may receive a Location Information Answer (LIA) via an Interrogating Call Session Control Function (ICSCF) from the IBCF associated with at least one of the first user device, the second user device of the first user, along with the first user information.

[0025] In one embodiment, the first user device corresponds to a central exchange (Centrex) / Internet Protocol (IP) Centrex user device and the second user device corresponds to a Session Initiation Protocol (SIP) trunking user device.

[0026] In another aspect, the present disclosure further provides a method for a universal central exchange (Centrex). The method includes receiving a short code dialed by a first user from at least one of a first user device to a second user device, a second user device to a second user device, and an inter-circle / intra-circle first user device. The second user device is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs). The method further includes determining whether the received short code is at least one of a SIP trunking code or an IP Centrix / Centrex code. The method further includes, based on the determination, converting the received short code into an associated Uniform Resource Identifier (URI) corresponding to at least one of the SIP trunking code or the IP Centrix / Centrex code. The short code corresponds to at least one of a fixed-line number and a mobile phone number. The method then includes performing at least one of E.164 number-to-URI mapping (ENUM) and mobile number portability (MNP) for the URI. The method further includes sending a SIP INVITE request to invite a second user to associate with at least one of the first user devices for a session. The SIP INVITE includes a URI address along with a domain name associated with the second user. The method further includes sending a caller ringback tone (CRBT) to the first user while, upon receiving a SIP INVITE response from the second user, calling a second user associated with at least one of the first user device and the second user device. The method further includes processing the call between the first user and the second user based on receiving the call by the second user after calling the second user associated with at least one of the first user device and the second user device.

[0027] In another aspect, the present disclosure relates to user equipment for a general purpose central exchange, the user equipment including: a processor coupled to a processor of a network device; and a memory coupled to the processor, the memory including processor-executable instructions for causing the processor to transmit a short code dialed by a first user associated with the user equipment to a second user associated with second user equipment, the second user equipment being communicatively coupled to one or more IP PBXs to receive the CRBT and process calls between the first and second users.

[0028] In another aspect, as noted above, the present disclosure relates to a non-transitory computer-readable medium that includes processor-executable instructions that cause a processor to perform the steps of this method.

[0029] The accompanying drawings, which are incorporated herein and constitute a part of this specification, depict exemplary embodiments of the disclosed method and system, in which like reference numerals refer to the same parts throughout the different drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the invention. Some drawings may use block diagrams to illustrate components and may not show the internal circuitry of each component. Those skilled in the art will appreciate that the inventions in such drawings include inventions in electrical or electronic components or circuits commonly used to implement such components. [Brief explanation of the drawings]

[0030] [Figure 1] 1 illustrates a block diagram representation of an exemplary network architecture in which or by which the disclosed system may be implemented for a general purpose central exchange (Centrex), in accordance with one embodiment of the present disclosure. [Figure 2] FIG. 2 illustrates an exemplary block diagram representation of a server for a general purpose central exchange (Centrex), according to one embodiment of the present disclosure. [Figure 3]FIG. 1 illustrates an exemplary block diagram representation of network services provided to multiple entities or enterprises, according to one embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates an exemplary block diagram representation of a Business Telephony Application Server (BTAS) integration architecture, according to one embodiment of the present disclosure. [Figure 5] 1 illustrates an exemplary block diagram representation of a generic Centrex service architecture, according to one embodiment of the present disclosure. [Figure 6] 2 is an exemplary sequence diagram for a generic Centrex intra-enterprise / inter-enterprise call flow between Session Initiation Protocol (SIP) trunking and a Centrex / IP Centrex user according to one embodiment of the present disclosure. [Figure 7] 1 is an exemplary flowchart of a universal central exchange (Centrex) method according to one embodiment of the present disclosure. [Figure 8] FIG. 1 illustrates an exemplary computer system in which or by which embodiments of the present invention may be utilized, in accordance with embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0031] The above will become more apparent from the following more detailed description of the invention.

[0032] In the following description, for purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. However, it will be apparent that embodiments of the present disclosure may be practiced without these specific details. Some features described hereafter may be used independently of each other or in any combination with other features. Individual features may not address all of the problems described above, or may address only some of the problems described above. Some of the problems described above may not be completely addressed by any of the features described herein.

[0033] The following description merely provides exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with an effective description for implementing the exemplary embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the invention as described.

[0034] Specific details are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0035] Also, it should be noted that particular embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0036] The words “exemplary” and / or “demonstrative” are used herein to mean serving as an example, illustration, or aid in explanation. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. Additionally, any aspect or design described herein as “exemplary” and / or “exemplary” is not necessarily to be construed as desirable or advantageous over other aspects or designs, and is not intended to exclude equivalent exemplary structures and techniques known to those skilled in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar terms are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word, without excluding any additional or other elements.

[0037] References throughout this specification to "one embodiment," or "an embodiment," or "an instance," or "one instance" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0038] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Furthermore, it will be understood that the terms "comprises" and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0039] Various embodiments of the present disclosure provide network devices and methods for a universal central exchange (Centrex). The present disclosure provides a network device to be integrated into an operator's Internet Protocol Multimedia Subsystem (IMS) core network. The present disclosure provides universal Centrex service as a value-added service over any of the existing voice services, namely SIP trunk, Centrex, IP Centrex, and Society Centrex. The present disclosure enables universal Centrex service with abbreviated dialing between Centrex / IP Centrex users and SIP trunking users, between SIP trunking users, and between inter-circle / intra-circle Centrex / IP Centrex users, within the same city or across the country. The present disclosure enables porting of plain old telephone service (POTS) phones to IP without incurring the cost of a private branch exchange (PBX), and also allows customers to enjoy the benefits of dialing between an Internet Protocol (IP) PBX and a new universal Centrex user. The present disclosure supports abbreviated number dialing between Centrex / IP Centrex to SIP trunking users and SIP trunking to SIP trunking or inter-circle / intra-circle Centrex / IP Centrex users. The present disclosure enables private number patterns (e.g., 2 / 3 / 4 / 5 / 6 digits) nationwide. The present disclosure merges multiple SIP trunks with one main number (same location, same authorized signatory, same billing identity, etc.). The present disclosure enables existing setups as well as new setups under one Centrex group.

[0040] Referring to FIG. 1, FIG. 1 illustrates a block diagram of an exemplary network architecture for a general-purpose central exchange (Centrex) system 100 (also referred to as network architecture 100) in which or by which a network device 102 of the present disclosure may be implemented, according to one embodiment of the present disclosure. The network device may be a Business Telephony Application Server (BTAS) (hereinafter interchangeably referred to as network device or BTAS). The network device / BTAS 102 may be integrated with a vendor Internet Protocol Multimedia Subsystem (IMS) server 106 of a core network. The core network may include, but is not limited to, a third-generation (3G) network, a fourth-generation (4G) network, a fifth-generation (5G) network, a sixth-generation (6G) network, a wireless fidelity (Wi-Fi) network, any other wireless network, or a combination thereof. The BTAS 102 may provide services such as Session Initiation Protocol (SIP) trunking and Internet Protocol (IP) central exchange (Centrex) services to users. The BTAS (102) may be integrated with an IMS core network and other application servers to provide supplementary services such as, but not limited to, closed user groups (CUGs), short code dialing, conferencing, etc. The BTAS (102) may be a SIP application server that may be combined in different ways for different SIP network solutions. Various functional components of the BTAS (102) may include, but are not limited to, a SIP application server with enterprise features, access elements, and clients such as IP phones, IP private branch exchanges (PBXs), enterprise session border controllers (ESBCs), operation, administration, and management via an element management server (EMS) (108), a provisioning server, an IMS network, etc.

[0041] The BTAS 102 may further be operatively coupled to one or more user equipment (UE) devices (110-1, ..., 110-N) (collectively referred to as UEs 110 and individually referred to as UEs 110) associated with a user via a communications network 112. The UEs 110 may be connected to the BTAS 102 via an IMS server 106. The BTAS 102 may be communicatively coupled to an entity (not shown in FIG. 1). The entity may include, but is not limited to, a company, an organization, a network operator, a vendor, a retailer, a storage facilitator, a university, a research facility, a business enterprise, a defense facility, or any other secure facility. Additionally, the entity may analyze data or output from the BTAS 102. In some implementations, the system 110 may also be associated with a computing device.

[0042] Although Figure 1 illustrates example components of network architecture (100), in other implementations, network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components relative to those shown in Figure 1. Additionally or alternatively, one or more components of network architecture (100) may perform functions described as being performed by one or more other components of network architecture (100).

[0043] The BTAS (102) may be implemented in, but is not limited to, an electronic device, a mobile device, a wireless device, a wired device, a server, etc. Such servers may include, but are not limited to, a stand-alone server, a remote server, a cloud server, a dedicated server, etc.

[0044] In one embodiment, the BTAS (102) may include one or more processors coupled to a memory that may store instructions that, when executed by the one or more processors, cause the BTAS (102) to provide a general-purpose central exchange (Centrex). An exemplary representation of the BTAS (102) relative to a general-purpose central exchange (Centrex) according to one embodiment of the present disclosure is shown in FIG. 2. In one aspect, the BTAS (102) may include one or more processors (202). The one or more processors (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operational instructions. Among other capabilities, the one or more processors (202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the BTAS (102). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium that can be fetched and executed to generate or share data packets over the network service. The memory (204) may include any non-transitory storage device, including, for example, volatile memory such as RAM or non-volatile memory such as EPROM, flash memory, etc.

[0045] In one embodiment, the BTAS (102) may include an interface (206). The interface (206) may include various interfaces, such as interfaces to data input and output devices, referred to as I / O devices, storage devices, etc. The interface (206) may facilitate communication with the centralized server (110). The interface (206) may also provide a communication path for one or more components of the BTAS (102). Examples of such components include, but are not limited to, a processing unit / engine (208) and a database (210).

[0046] The processing unit / engine (208) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing engine (208). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the processing engine (208) may include processing resources (e.g., one or more processors) to execute such instructions. In this example, the machine-readable storage medium may store instructions that, when executed by the processing resources, implement the processing engine (208). In accordance with such an example, the BTAS (102) may include a machine-readable storage medium that stores instructions and processing resources for executing the instructions, or the machine-readable storage medium may be separate but accessible to the BTAS (102) and the processing resources. In other examples, the processing engine (208) may be implemented by electronic circuitry.

[0047] The processing engine 208 may include one or more modules / engines selected from any of a receiving module 212, a determining module 214, a transforming module 216, an executing module 218, a transmitting module 220, a processing module 222, and other modules 224. The processing engine 208 may also be, but is not limited to, edge-based microservice event processing.

[0048] In one embodiment, the receiving module (212) can receive a short code dialed by a first user. The first user can dial from at least one of the following: from the first user device to the second user device, from the second user device to the second user device, and from the first user device between / within circles. The first user device can be a central exchange (Centrex) / Internet Protocol (IP) Centrex user device, and the second user device can be a Session Initiation Protocol (SIP) trunking user device. Such a device can be a UE (110) (hereinafter, the first user device can be referred to as a Centrex / IP Centrex user device / first user device / UE, and the second user device can be referred to as a SIP trunking device / second user device / UE). The second / SIP trunking user device (110) can be communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) (not shown in FIG. 1 ). The short code may be received from at least one of a Centrex / IP Centrex user device and a SIP trunking user device via an Enterprise Session Border Controller (ESBC), a Proxy Call Session Control Function (PCSCF), or a Serving Call Session Control Function (SCSCF), and the ESBC forwards the traffic to an Internet Protocol Multimedia Subsystem (IMS) core network, which is a common IMS architecture deployed within an operator environment.

[0049] In one embodiment, the determination module (214) may determine whether the received short code is at least one of a SIP trunking code or an IP centric / centrex code. In one embodiment, the conversion module (216) may convert the received short code into an associated uniform resource identifier (URI) corresponding to at least one of a SIP trunking code or an IP centric / centrex code based on the determination. The short code corresponds to at least one of a fixed-line number and a mobile phone number. The SIP trunking code or IP centric / centrex code may be determined based on an area code associated with the short code dialed by the first user.

[0050] In one embodiment, the execution module (218) may perform at least one of E.164 number to URI mapping (ENUM) for the URI and mobile number portability (MNP). In one embodiment, the sending module (220) may send a credit control request (CCR) to an online charging server (OCS) and receive a credit control answer (CCA) from the OCS upon performing at least one of the ENUM and MNP for the URI.

[0051] In one embodiment, upon receiving the CCA from the OCS, the sending module (220) may send a Location Information Request (LIR) for the first user information to an Interconnection Border Control Function (IBCF) associated with at least one of the first user's Centrex / IP Centrex user device and SIP trunking user device via the SCSCF. Further, the receiving module (212) may receive a Location Information Answer (LIA) along with the first user information from the IBCF associated with at least one of the first user's Centrex / IP Centrex user device and SIP trunking user device via an Interrogation Call Session Control Function (ICSCF).

[0052] In one embodiment, the sending module (220) may send a SIP INVITE request to invite a second user associated with at least one of the Centrex / IP Centrex user devices to the session, the SIP INVITE including a URI address along with a domain name associated with the second user.

[0053] In one embodiment, the BTAS (102) may merge multiple SIP trunking user devices with one main number, which is associated with the same location, the same authorized signatory, and the same billing identity.

[0054] In one embodiment, the transmitting module (222) may transmit a caller ringback tone (CRBT) to the first user, while, upon receiving a SIP INVITE response from the second user, making a call to the second user associated with at least one of a Centrex / IP Centrex user device and a SIP trunking user device.

[0055] In one embodiment, the processing module (224) may process a call between a first user and a second user based on making a call to the second user associated with at least one of a Centrex / IP Centrex user device and a SIP trunking user device and then receiving a call by the second user. The call may be originated from an Enterprise Session Border Controller (ESBC) (not shown in FIGS. 1 and 2), and the BTAS (102) maintains all number configurations associated with the SIP trunk, the Centrex / IP Centrex, and their respective Closed User Group (CUG) definitions.

[0056] In one embodiment, the UE (110) or computing device (not shown in FIGS. 1 and 2) may communicate with the BTAS (102) via a set of executable instructions present on any operating system. In one embodiment, the electronic device may include any electrical, electronic, electromechanical equipment, such as, but not limited to, a mobile phone, a smartphone, a virtual reality (VR) device, an augmented reality (AR) device, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device, or a combination of one or more of the above devices. The computing device may include one or more built-in or external accessories, including, but not limited to, a visual aid such as a camera, a hearing aid, a microphone, a keyboard, an input device for receiving input from a user, such as a touchpad, a touch-enabled screen, an electronic pen, etc. It should be appreciated that the electronic device may not be limited to the above-mentioned devices, and various other devices may be used. The smart computing device may be one of a variety of suitable systems for storing data and other private / confidential information.

[0057] 3 illustrates an exemplary block diagram representation of network services provided to multiple entities or enterprises according to one embodiment of the present disclosure. The network services (corresponding to 112 in FIG. 1) may be provided to multiple entities or enterprises, such as, for example, Enterprise-1 (354-1), Enterprise-2 (354-2), Enterprise-3 (354-3), and Enterprise-4 (354-4) (collectively referred to as Enterprises (354) and individually as Enterprises (354)). In one embodiment, at least one of the enterprises 354 may include an IP private branch exchange (IP PBX) to enable switching of calls between UEs (110) on local lines, and each enterprise (154) may communicate with a communication network / server via an enterprise session border controller (ESBC) (356-1, 356-2, 356-3, 356-4) (collectively referred to as ESBCs (356)). As shown in FIG. 1 , each enterprise, e.g., Enterprise-1 (354-1), Enterprise-2 (354-2), Enterprise-3 (354-3), and Enterprise-4 (354-4), may be facilitated by network services (e.g., 4G / 5G / 6G network services) via ESBCs (356-1, 356-2, 356-3, and 356-4), respectively. The ESBC (356) may be a set of executable instructions for enabling connectivity and security associated with enterprise and service provider networks. An IP PBX may be a private branch exchange (PBX) or telephone switching system within the enterprise, which may, for example, enable switching calls between users within the enterprise. In one embodiment, the BTAS (102) may be communicatively coupled to other components, such as, for example, IP phones and provisioning servers. In an exemplary embodiment, the IP PBX may communicate with the ESBC (356) via Session Initiation Protocol (SIP) techniques.An enterprise may refer to an entity including, but not limited to, an organization, company, business, educational campus, office campus, shopping center, residential area / community, and various other entities that may desire to utilize a communication network provided by a service provider. In one embodiment, the communication network may be available only within a predetermined zone (authorized zone) of the enterprise. Various other types of entities / provisions are possible.

[0058] The IMS server (106 in FIG. 1) may include one or more modules or components that may enable it to perform one or more functions. For example, the IMS server may be an existing IMS core that includes components / modules that handle various functions, such as a Serving Call Session Control Function (SCSCF) module (358), an Interrogating Call Session Control Function (ICSCF) module (362), and a Proxy Call Session Control Function (PCSCF) module (352). In one embodiment, the BTAS (102) may be integrated with the IMS core and a network of other application servers to provide network services related to, for example, 4G / 5G / 6G networks. For example, the other application servers may include a Telephony Application Server (TAS) (360), which may be considered a general component used within a communications network to provide telephony applications and additional multimedia capabilities. In another example, other application servers may include a mobile number portability (MNP) server (324), which may provide number portability for users, such as allowing them to retain the same number when switching within a service provider. Various other servers may be integrated into a BTAS-enabled IMS implementation to enable one or more services related to a communication network or a 4G / 5G / 6G network without departing from the scope of the proceeding description.

[0059] With respect to IMS-related components, the SCSCF module 358 may be the primary node within the IMS server 106 responsible for session control. In one embodiment, a list of subscribers may be assigned to each SCSCF module 358 at the time of IMS registration to facilitate routing of SIP messages as part of the service establishment procedure. In operation, the SCSCF module 358 may enable downloading of subscriber profiles from the Home Subscriber Server (HSS) 320 at the time of IMS registration. The ICSCF module 362 may be a key element in the IMS server 106 and may enable any request to be routed to the appropriate SCSCF module 358 from multiple SCSCFs within the network. The ICSCF module 362 may also query the HSS 320 to obtain the address of the associated SCSCF module 358 to process SIP initiation requests. As shown in Figure 3, the PCSCF module (352) may serve as an ingress and egress point for IMS clients into and out of the service provider's IMS domain. The PCSCF module (352) may perform general functions such as, for example, onward routing of registration and session requests to the correct node in the communication network, updating the SCSCF module (358), maintaining a secure connection with the UE (110), and other such functions. In one embodiment, the network device or BTAS (102) may be communicatively coupled to or integrated with one or more functional components, such as, for example, a Session Initiation Protocol (SIP)-based application server. The SIP server may be configured with features related to the type of enterprise (354).

[0060] Furthermore, as shown in FIG. 3 , to provide various aspects of network services (e.g., related to 4G / 5G / 6G networks), the components of the IMS server (106) (e.g., SCSCF, ICSCF modules) may also include components / modules related to other functions. For example, the components / modules may correspond to a Breakout Gateway Control Function (BGCF) module (318), a Media Gateway Control Function (MGCF) module (322), an Interconnect Border Control Function (IBCF) (316), and other components / modules. In a typical implementation, the BGCF module (318) may enable routing call signaling to and from the most appropriate SCSCF module (358). In this implementation, the BGCF module (318) may enable routing of calls to the respective BTAS (102) for generic Centrex services. In general, the MGCF module 322 may be a SIP endpoint capable of interfacing with a security gateway (SGW) and may also control resources within the media gateway (MGW) 330. The IBCF module 316 may enable boundary control between various service provider networks, thus providing BTAS-enabled IMS network security with respect to signaling information. The IMS server 106 may also include other existing components, such as components associated with a multimedia resource function (MRF) module 326. The MRF module 326, in conjunction with other components of the IMS server 106, may be responsible for performing various processing tasks on media streams associated with a particular service. Furthermore, as shown in FIG. 3, a BTAS-IMS-based implementation may be associated with a point of interconnection (POI) 334, which may be a physical interface between media gateways of various service providers or enterprises.

[0061] FIG. 4 illustrates an exemplary block diagram representation of a business telephony application server (BTAS) integration architecture (400) according to one embodiment of the present disclosure. The BTAS / network device (102) may be integrated with or coupled to various hardware / software components or servers to enable one or more functions related to generic Centrex services. The BTAS (102) may be integrated with an IMS server (106) to enable communication processing related to UEs (116) within the enterprise (354) (shown in FIG. 3). In one exemplary embodiment, the BTAS (102) may be integrated with the IMS server (106) to establish and control communication connections via network protocols, including, but not limited to, the Session Initiation Protocol (SIP). Because communications may also involve the use of one or more forms of media, the BTAS (102) may be integrated with a multimedia resource function (MRF) (326). The BTAS (102) may interface with an Enterprise Provisioning Server (EPS) (104) via the representational state transfer (REST) ​​protocol to enable provisioning of service data.

[0062] In one exemplary embodiment, the BTAS (102) may integrate with the MRF (326) to enable functionality such as media mixing, control of announcements, and other such purposes via network protocols including, for example, but not limited to, Session Initiation Protocol-Media Server Markup Language (SIP-MSML). In one exemplary embodiment, the BTAS (102) may be integrated or coupled with other components / services, such as Mobile Number Portability (MNP) (324) (via SIP) to enable number portability dipping. In another exemplary embodiment, the BTAS (102) and EPS (104) may be individually integrated or coupled with an Element Management System (EMS) (108) via REST. The EMS (108) may include hardware and software implementations for managing five key aspects, namely, fault, configuration, billing, performance, and confidentiality (FCAPS) functions, via the Representational State Transfer (REST) ​​protocol to exchange messages related to these key aspects, which may use the Hypertext Transfer Protocol (HTTP) to transport the messages. The EMS (108) may provide a foundation for implementing an Operations Support System (OSS) (402) or Business Support System (BSS) (402)-based architecture, enabling service providers to satisfy customer needs, for example, for rapid deployment of services to enable the delivery of satisfactory quality of service requirements and other such services. The EMS (108) may interface with the OSS / BSS (402) via the REST protocol to enable a northbound interface to the FCAPS data of the BTAS (102) / EPS (104). The term northbound interface may refer to an interface that allows a particular component of a network to communicate with a higher-level component. The OSS / BSS (402) may interface with the EPS (104) via the REST protocol to enable functions such as service data management requests, for example.

[0063] Additionally, as shown in FIG. 4, the BTAS (102) may be integrated or coupled with a Diameter Routing Agent (DRA) (408) via the diameter protocol, which may be a standard protocol for authentication, authorization, and charging information within an IMS server (106)-based network. The diameter DRA may be a functional element that can provide real-time routing capabilities to ensure messages are routed between the correct elements within the network. The BTAS (102)'s integration with the DRA (408) may enable integration with an Online Charging System (OCS) (410) to facilitate "Ro" charging. The OCS (410) may be a system that allows service providers to charge users or customers based on service usage in real time, and Ro charging relates to a protocol that allows triggers to generate charging events. In one embodiment, the BTAS (102) may also be integrated with components related to customized caller ringback tones (CRBTs) (406) to enable personalized ringback tones (RBTs) during the communication establishment phase. For example, this may primarily relate to an RBT that may be sounded during connection of a call communication of a user device with multiple emergency services.

[0064] Figure 5 shows an exemplary block diagram representation of a generic Centrex service architecture (500) according to one embodiment of the present disclosure. Generic Centrex services can be value-added services over any of the existing voice services, namely SIP trunk, IP Centrex, and Society Centrex. Generic Centrex services can enable abbreviated number dialing between Centrex / IP Centrex users and SIP trunking users, between SIP trunking users, and between inter-circle / intra-circle Centrex / IP Centrex users, within the same city or across the country. As shown in Figure 5, the generic Centrex service architecture (500) can be access independent, and the generic Centrex service can be based on one or more network operators' fixed-line IMS (106) core networks with additional elements such as a Business Telephony Application Server (BTAS) (102) that holds all Centrex-specific user features and business logic.

[0065] As shown in FIG. 5, the generic Centrex architecture may include two service architectures, such as SIP trunking service and Centrex / IP Centrex service. The SIP trunking service and Centrex / IP Centrex service may be combined with underlying access network connectivity. The SIP trunking service enterprise (506) may include an IP PBX (504) and connect to the ESBC 356 via an L3 router (502-1). The IP PBX (504) may be a private branch exchange (Private Branch Exchange) that switches calls between Voice over Internet Protocol (VoIP) users on local lines while allowing all users to share a certain number of external telephone lines. Furthermore, the Centrex / IP Centrex service may include plain old telephone service (POTS) telephones (512-1, 512-2), which are connected to integrated access devices (510, 518), respectively. The IADs (510, 518) may be customer premise devices that can provide access to a wide area network (WAN) and the Internet. Specifically, the IADs (510, 518) may connect a POTS line on one end and provide IP connectivity on the other end. User equipment (UE) management and configuration may be based on the type of model with the type of network operator that may need to market. UE management and provisioning may be important if the UE is managed by the network operator for general-purpose Centrex services. Furthermore, an automatic configuration system (ACS) / unified device manager (UDM) (514) may be required for UE auto-configuration, such as for the IADs (510, 518) or IP phones (516-1, 516-2). The IP phones (516-1, 516-2) may be HD audio and video phones. The IADs (510, 518) may be connected to a power over Ethernet (PoE) switch (508) and an optical network terminal (ONT) (520), respectively.For example, a fiber to the x (FTTx) / multiprotocol label switching (MPLS) access network may allow enterprise customers to connect to an operator network to access their services. However, customer premise equipment such as an ONT (520) may need to be installed. The home gateway or ONT (520) may be part of an existing FLP service offering to residential users, or the home gateway or ONT (520) may be used for new or existing customers requesting Society Centrex services at the apartment complex level. The PoE switch (508) and ONT (520) may be communicatively connected to an L3 router (502-2) and a broadband network gateway (BNG) (522), respectively. The L3 routers (502-1, 502-2) may be customer premise equipment for enterprise customers, which may need to be installed at the customer premise as part of a multiprotocol label switching (MPLS) Ethernet access to provide them with access to the operator network.

[0066] Enterprise SBCs (ESBCs) (356) may be deployed in designated circles across the country, and the ESBCs 356 may have SIP trunking services and logical SIP connections with Centrex / IP Centrex customers. The ESBCs may forward call traffic to the IMS (106) core network, which may be a common IMS architecture deployed within a network operator environment. For example, BTASs (102) may be deployed in eight super core locations. Each super core location may handle traffic for multiple circles that may be parented to a particular super core. The universal Centrex may enable POTS phones (512-1, 512-2) to be ported to IP without incurring the cost of a PBX, and customers may enjoy the benefits of seamless dialing between the IP PBX (504) and new universal Centrex users. In such cases, the service provider may own and manage all the communications equipment and software necessary to implement a Centrex service (a virtual PBX service for enterprises) and then sell various services to customers. A generic Centrex may also allow customers to make short-number calls between two different setups, such as an IP-based PBX connected to the service provider via SIP trunking service and a Centrex / IP Centrex connected to the service provider as a Centrex service. A generic Centrex service suite may present many of the business features of the Centrex service and will also cover the features of the SIP trunking service.

[0067] In one embodiment, a universal Centrex may support abbreviated number dialing (using short codes) between users from a Centrex / IP Centrex to SIP trunking and users between SIP trunking or users of an inter-circle / intra-circle Centrex / IP Centrex. For example, short codes may include private number patterns (e.g., 2 / 3 / 4 / 5 / 6 digits) on a national basis. Abbreviated number dialing may not have numbers similar to emergency numbers and L1 codes. A universal Centrex may merge multiple SIP trunks with one main number (same location, same authorized signatory, same billing identity). Furthermore, existing and new setups may be brought under one Centrex group. Configuration of private number patterns may be provided via self-care (including abbreviated number dialing and access codes). A universal Centrex may support overlapping abbreviated number dialing between users from a Centrex / IP Centrex to SIP trunking and users between SIP trunking or users of an inter-circle / intra-circle Centrex / IP Centrex. Generic Centrex enables CUG dialing between SIP trunking user devices and Centrex / IP Centrex user devices.

[0068] In an alternative embodiment, an inter short code, such as a local short, can be dialed by the first user and processed locally using the PBX / IP PBX or Centrex without sending the inter short code to the BTAS (102) for processing. The inter short code may not include any area code. When the short code includes an area code, the short code with the area code may be sent to the BTAS (102) for processing the call. Furthermore, in one embodiment, the charges for the IP PBX and Centrex are the same as the normal charging rate (i.e., the rate from the IP PBX to the Centrex) used for charging without the generic Centrex service. However, the charges may differ with the proposed generic Centrex service.

[0069] FIG. 6 illustrates an exemplary sequence diagram for a generic Centrex intra-enterprise / inter-enterprise call flow between Session Initiation Protocol (SIP) trunking and a Centrex / IP Centrex user, according to one embodiment of the present disclosure.

[0070] As shown in Figure 6, circle "A" may include an IP PBX (SIP trunking device) associated with user "A," such as a first user, and a Centrex / IP Centrex associated with user "B," such as a second user. Further, circle "A" may include an ESBC (356), a PCSCF (352), and an IBCF (316). Further, supercore "A" may include an ICSCF (362), an SCSCF-1 (358-1), a BTAS-1 (102-1), an OCS (410), a CRBT (406), an MRF (326), an SCSCF-2 (358-2), and a BTAS-2 (102-2).

[0071] In step (602), an INVITE short code is sent from the IP PBX User A device to BTAS-1 (102-1) via the ESBC (356), PCSCF (352), and SCSCF (358-1). In step (604), BTAS-1 (102-1) may trigger billing to the OCS (410) using a credit control request (CCR), and in step (606), the OCS (410) may send a credit control answer (CCA) back to BTAS-1 (102-1). In step (608), BTAS-1 (102-1) may convert the short code to a URI (i.e., a complete number).

[0072] In step (610), the BTAS-1 (102-1) may perform at least one of E.164 number-to-URI mapping (ENUM) and mobile number portability (MNP) for the URI. In step (612), upon receiving the INVITE, the BTAS-1 (102-1) may trigger the ICSCF (362) to query the HSS (not shown in FIG. 6) to discover the S-CSCF-1 (358-1) allocated for user A via a Location Information Request (LIR) Diameter request. The HSS then returns the allocated S-CSCF-1 (358-1) using the mapping in the answer via a Location Information Answer (LIA).

[0073] In step (614), the ICSCF (362) may send a SIP INVITE containing User B's URI to the SCSCF-2 (358-2), which may then send the SIP INVITE to the BTAS-2 (102-2) in step (616). In step (618), the BTAS-2 (102-2) may use a credit control request (CCR) to trigger charging to the OCS (410), and in step (620), the OCS (410) may again send a credit control answer (CCA) to the BTAS-2 (102-2).

[0074] In step (622), the BTAS-2 (102-2) may forward the SIP INVITE to the SCSCF-2 (358-2). In step (624), the SCSCF-2 (358-2) may forward the SIP INVITE to the PCSCF (352), which may then forward the SIP INVITE to the ESBC (356). Furthermore, the ESBC (356) may send the SIP INVITE to User B's device.

[0075] In step (626), the user B device returns the call to the ESBC (356) using a 180 call origination message, which then sends the 180 call origination message to the PCSCF (352). The PCSCF (352) then sends the 180 call origination message to the SCSCF-2 (358-2). The SCSCF-2 (358-2) then sends the 180 call origination message to the BTAS-2 (102-2).

[0076] In step (628), BTAS-2 (102-2) sends a 180 call message to SCSCF-2 (358-2), which then sends the 180 call message to IBCF (316). In step (630), IBCF (316) sends a 180 call message to SCSCF-1 (358-1), which then sends the 180 call message to BTAS-1 (102-1).

[0077] In step (632), the BTAS-1 (102-1) sends a 180 call origination message to the user A device via the SCSCF-1 (358-1), the IBCF (316), the PCSCF (352), and the ESBC (356). In step (634), the BTAS-2 (102-2) sends an INVITE message containing a message to user B (P=early media) to the CRBT (406). Early media is the ability for two SIP user agents to communicate before a SIP call is established. Typically, this scenario occurs when the called party is a PSTN gateway. Before the call is set up, the gateway may provide in-band tones or announcements to inform the caller of the call's progress. The P-Early Media header is used to request and authorize requests for backward and / or forward early media. The P-Early media header field in the INVITE request contains the "supported" parameter.

[0078] In step 636, the CRBT 406 may send a 200 OK message to the BTAS-2 102-2 along with the Session Description Protocol (SDP) for the CRBT. In step 638, the BTAS-2 102-2 may send the 183 session in a progress message along with a P-Early Media Send Only message to the IBCF 316 via the SCSCF-2 358-2, and then to the BTAS-1 102-1 via the SCSCF-1 358-1. The "Send Only" value indicates a request for authorization of early media (backward early media) from the SCSCF-1 358-1 to the BTAS-1 102-1, but not in the opposite direction.

[0079] In step 640, the BTAS-1 (102-1) sends a session in progress message 183 to the SCSCF-1 (358-1), which then sends the session in progress message 183 to the ESBC (356). The ESBC (356) then sends the session in progress message 183 to the user A device.

[0080] In step (642), the user A device sends a Provisional Response Acknowledgement (PRACK) message to the ESBC (356), which then sends the PRACK to the PSCSF (352). The PSCSF (352) then sends the PRACK to the SCSCF-1 (358-1), which then sends the PRACK to the BTAS-1 (102-1). For example, in a SIP interworking scenario, the 180 and 183 messages must not be omitted, and therefore the PRACK is sent. The BTAS-1 (102-1) then sends the PRACK to the IBCF (316) via the SCSCF-1 (358-1).

[0081] In step (644), the PRACK is sent from the IBCF (316) to the SCSCF-2 (358-2), which then sends the PRACK message to the BTAS-2 (102-2). In step (646), the BTAS-2 (102-2) sends the SDP information included in the PRACK message to the CRBT (406). In step (648), the CRBT (406) sends a 200 OK message to the BTAS-2 (102-2). The BTAS-2 (102-2) then sends a 200 OK message to the IBCF (316).

[0082] In step (650), a 200 OK message is sent from the IBCF (316) to the BTAS-1 (102-1) via the SCSCF-1 (358-1). In step (652), the BTAS-1 (102-1) forwards the 200 OK message to the user A device via the SCSCF-1 (358-1), the PCSCF (352), and the ESBC (356). In step (654), the MRF (326) sends the media to the user device "A" via the BGW (332).

[0083] FIG. 7 illustrates an exemplary flow chart for a universal central exchange (Centrex) method (700) according to one embodiment of the present disclosure.

[0084] In block 702, the method 700 may include receiving, by a processor 202 associated with the network device 102, a short code dialed by a first user of at least one of: from a first user device 110 to a second user device 110; from a second user device 110 to a second user device 110; and of an inter-circle / intra-circle first user device 110. The second user device 110 is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) 504.

[0085] At block 704, the method 700 includes determining, by the processor 202, whether the received short code is at least one of a SIP trunking code or an IP Centrix / Centrex code.

[0086] At block (706), the method (700) may include, based on the determination, converting, by the processor (202), the received short code into an associated uniform resource identifier (URI) corresponding to at least one of a SIP trunking code or an IP centric / centrex code, the short code corresponding to at least one of a fixed line number and a mobile phone number.

[0087] At block 708, the method 700 may include performing, by the processor 202, at least one of E.164 number to URI mapping (ENUM) and mobile number portability (MNP) for the URI.

[0088] At block (710), the method (700) may include sending, by the processor (202), a SIP INVITE request to invite a second user to associate with at least one of the first user devices (110) for a session, the SIP INVITE including a URI address along with a domain name associated with the second user.

[0089] In block (712), the method (700) may include a step of sending a caller ringback tone (CRBT) (406) to the first user by the processor (202), while, upon receiving a SIP INVITE response from the second user, placing a call to a second user associated with at least one of the first user device (110) and the second user device (110).

[0090] In block (714), the method (700) may include a step of processing, by the processor (202), a call between the first user and the second user based on making a call to the second user associated with at least one of the first user device (110) and the second user device (110) and then receiving a call by the second user.

[0091] FIG. 8 illustrates an exemplary computer system (800) in or by which embodiments of the present disclosure may be utilized, according to embodiments of the present disclosure.

[0092] As shown in FIG. 8 , the computer system (800) may include an external storage device (810), a bus (820), a main memory (830), a read-only memory (840), a mass storage device (850), a communications port (860), and a processor (870). Those skilled in the art will appreciate that a computer system may include more than one processor and communications port. The processor (870) may include various modules related to embodiments of the present invention. The communications port (860) may be an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or any other existing or future port. The communications port (860) may be selected depending on the network, such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system connects. The memory (830) may be random access memory (RAM) or any other dynamic storage device commonly known in the art. The read-only memory (840) may be any static storage device, such as, but not limited to, a programmable read-only memory (PROM) chip for storing static information, such as boot or BIOS instructions for the processor (870). The mass storage (850) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, parallel advanced technology attachment (PATA) or serial advanced technology attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., with universal serial bus (USB) and / or Firewire interfaces).

[0093] The bus (820) communicatively couples the processor (870) to other memory, storage, and communication blocks. The bus (820) may be, for example, a Peripheral Component Interconnect (PCI) / PCI Expansion (PCI-X) bus, a Small Computer System Interface (SCSI), USB, etc. for connecting expansion cards, drives, and other subsystems, as well as other buses such as a Front Side Bus (FSB) that connect the processor (870) to a software system.

[0094] Optionally, operator and administrative interfaces, such as a display, keyboard, and cursor control devices, may also be coupled to the bus 820 to support direct operator interaction with the computer system. Other operator and administrative interfaces may be provided via a network connection connected via the communications port 860. The external storage device 810 may be any type of external hard drive, floppy drive, IOMEGA® Zip drive, compact disk read-only memory (CD-ROM), rewritable compact disk (CD-RW), or digital video disk read-only memory (DVD-ROM). The components described above are merely meant to illustrate various possibilities. The exemplary computer system described above in no way limits the scope of this disclosure.

[0095] Various embodiments of the present disclosure provide network devices and methods for a universal central exchange (Centrex). The present disclosure provides a network device to be integrated into an operator's Internet Protocol Multimedia Subsystem (IMS) core network. The present disclosure provides universal Centrex service as a value-added service over any of the existing voice services, namely SIP trunk, Centrex, IP Centrex, and Society Centrex. The present disclosure enables universal Centrex service with abbreviated dialing between Centrex / IP Centrex users and SIP trunking users, between SIP trunking users, and between inter-circle / intra-circle Centrex / IP Centrex users, within the same city or across the country. The present disclosure enables porting of plain old telephone service (POTS) phones to IP without incurring the cost of a private branch exchange (PBX), and also allows customers to enjoy the benefits of dialing between an Internet Protocol (IP) PBX and a new universal Centrex user. This disclosure supports abbreviated number dialing between Centrex / IP Centrex to SIP trunking users and SIP trunking to SIP trunking or inter-circle / intra-circle Centrex / IP Centrex users. This disclosure enables private number patterns (2 / 3 / 4 / 5 / 6 digits) nationwide. This disclosure merges multiple SIP trunks with one main number (same location, same authorized signatory, same billing identity, etc.). This disclosure enables existing setups as well as new setups under one Centrex group.

[0096] Although considerable emphasis has been placed herein on the preferred embodiment, it will be appreciated that many embodiments may be made and that many changes may be made in the preferred embodiment without departing from the principles of the present invention. These and other changes in the preferred embodiment of the present invention will be apparent to those skilled in the art from the disclosure herein, and it should therefore be clearly understood that the foregoing description is merely an illustrative implementation of the present invention and is not limiting. [Explanation of symbols]

[0097] 100 General-purpose central exchange (Centrex) system, network architecture 102 Network Devices / Business Telephony Application Server (BTAS) 102-1 BTAS-1 102-2 BTAS-2 104 Enterprise Provisioning Server (EPS) 106 Internet Protocol Multimedia Subsystem (IMS) Server 108 Element Management Server (EMS) 110-1 User Equipment (UE) 110-N UE 112 Communication Network 116 UE 202 processors 204 memory 206 Interface 208 Processing Unit / Engine 210 databases 212 Receiver Module 214 Decision Module 216 Conversion Module 218 Execution Module 220 Transmitting Module 222 Processing Module 224 other modules 316 Interconnection Border Control Function (IBCF) 318 Breakout Gateway Control Function (BGCF) Module 320 Home Subscriber Server (HSS) 322 Media Gateway Control Function (MGCF) Module 324 Mobile Number Portability (MNP) 326 Multimedia Resource Function (MRF) Module 330 Media Gateway (MGW) 332 BGW 334 Points of Interconnection (POI) 352 Proxy Call Session Control Function (PCSCF) Module 354 Enterprise 354-1 Enterprise-1 354-2 Enterprise-2 354-3 Enterprise-3 354-4 Enterprise-4 356 Enterprise Session Border Controller (ESBC) 356-1 ESBC 356-2 ESBC 356-3 ESBC 356-4 ESBC 358 Serving Call Session Control Function (SCSCF) Module 358-1 SCSCF-1 358-2 SCSCF-2 360 Telephony Application Server (TAS) 362 Interrogation Call Session Control Facility (ICSCF) Module 400 BTAS Integrated Architecture 402 Operational Support System (OSS) / Business Support System (BSS) 406 Customized Caller Ringback Tone (CRBT) 408 Diameter Routing Agent (DRA) 410 Online Charging System (OCS) 500 Generalized Centrex Service Architecture 502-1 L3 router 502-2 L3 router 504 Internet Protocol Private Branch Exchange (IP PBX) 506 Enterprise 508 Power over Ethernet (PoE) Switch 510 Integrated Access Device 512-1 Plain Old Telephone Service (POTS) Phone 512-2 Plain Old Telephone Service (POTS) Phones 514 Automatic Configuration System (ACS) / Unified Device Manager (UDM) 516-1 IP phone 516-2 IP phone 518 Integrated Access Device 520 Optical Network Terminal (ONT) 522 Broadband Network Gateway (BNG) 800 Computer Systems 810 External storage device 820 Bus 830 Main Memory 840 Read-Only Memory 850 Mass Storage Device 860 communication port 870 processor

Claims

1. A network device (102) for a general purpose central exchange (Centrex), comprising: a processor (202); a memory (204) coupled to the processor (202), the memory (204) including processor-executable instructions that, when executed, cause the processor (202) to: receiving a short code dialed by a first user from at least one of a first user device (110) to a second user device (110), a second user device (110) to the second user device (110), and an inter-circle / intra-circle first user device (110), wherein the second user device (110) is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) (504); determining whether the received short code is at least one of a SIP trunking code or an IP Centrix / Centrex code; Based on the determination, converting the received short code into an associated Uniform Resource Identifier (URI) corresponding to the at least one of a SIP trunking code or an IP Centrix / Centrex code, wherein the short code corresponds to at least one of a fixed line number and a mobile phone number; performing at least one of E.164 number to URI mapping (ENUM) and mobile number portability (MNP) on the URI; sending a SIP INVITE request to invite a second user to associate with at least one of the first user devices (110) for a session, the SIP INVITE including a URI address along with a domain name associated with the second user; sending a caller ringback tone (CRBT) (406) to the first user while, upon receiving a SIP INVITE response from the second user, placing a call to the second user associated with at least one of the first user device (110) and the second user device (110); processing the call between the first user and the second user based on making a call to the second user associated with at least one of the first user device (110) and the second user device (110) and then receiving the call by the second user; A network device (102) performs the above.

2. 10. The network device of claim 1, wherein the short code is received from at least one of the first user device and the second user device via an Enterprise Session Border Controller (ESBC) (356), a Proxy Call Session Control Function (PCSCF), or a Serving Call Session Control Function (SCSCF), and the ESBC (356) forwards the traffic to an Internet Protocol Multimedia Subsystem (IMS) (106) core network, the IMS (106) core network being a common IMS architecture deployed within an operator environment.

3. 2. The network device (102) of claim 1, wherein at least one of the SIP trunking code or the IP centric / centrex code is determined based on an area code associated with the short code dialed by the first user.

4. 10. The network device (102) of claim 1, wherein the call originates from an Enterprise Session Border Controller (ESBC) (356), and the network device (102) maintains all number configurations associated with SIP trunks, Centrex / IP Centrex, and respective Closed User Group (CUG) definitions.

5. 10. The network device of claim 1, wherein the processor is further configured to merge multiple second user devices with a single main number, the main number being associated with the same location, the same authorized signatory, and the same billing identity.

6. 2. The network device of claim 1, wherein the processor is further configured to: send a credit control request (CCR) to an online charging server (OCS) upon executing at least one of the ENUM and the MNP for the URI and receive a credit control answer (CCA) from the OCS after a SIP INVITE for the second user associated with at least one of the first user device and the second user device.

7. The processor (202) Upon receiving the CCA from the OCS (410), sending a Location Information Request (LIR) via an SCSCF (358) to an Interconnect Border Control Function (IBCF) (316) associated with at least one of the first user device (110) and the second user device (110) of the first user regarding first user information; receiving a Location Information Answer (LIA) from the IBCF (316) associated with at least one of the first user device (110) and the second user device (110) of the first user together with the first user information via an Interrogation Call Session Control Function (ICSCF) (362); The network device (102) of claim 6, further configured to:

8. 10. The network device of claim 1, wherein the first user device corresponds to a central exchange (Centrex) / Internet Protocol (IP) Centrex user device and the second user device corresponds to a Session Initiation Protocol (SIP) trunking user device.

9. A method for a general purpose central exchange (Centrex), comprising: receiving, by a processor (202) associated with a network device (102), a short code dialed by a first user of at least one of a first user device (110) to a second user device (110), a second user device (110) to a second user device (110), and an inter-circle / intra-circle first user device (110), wherein the second user device (110) is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) (504); determining, by the processor (202), whether the received short code is at least one of a SIP trunking code or an IP Centrix / Centrex code; based on the determination, converting, by the processor (202), the received short code into an associated Uniform Resource Identifier (URI) corresponding to the at least one of a SIP trunking code or an IP Centrix / Centrex code, the short code corresponding to at least one of a fixed line number and a mobile phone number; performing, by the processor (202), at least one of E.164 number to URI mapping (ENUM) and mobile number portability (MNP) on the URI; sending, by the processor (202), a SIP INVITE request to invite a second user associated with at least one of the first user devices (110) to a session, the SIP INVITE including a URI address along with a domain name associated with the second user; transmitting a caller ringback tone (CRBT) (406) to the first user by the processor (202), while, upon receiving a SIP INVITE response from the second user, placing a call to the second user associated with at least one of the first user device (110) and the second user device (110); processing the call between the first user and the second user by the processor (202) based on receiving a call by the second user associated with at least one of the first user device (110) and the second user device (110) after making a call to the second user; A method comprising:

10. 10. The method of claim 9, wherein the short code is received from at least one of the first user device (110) and the second user device (110) via an Enterprise Session Border Controller (ESBC) (356), a Proxy Call Session Control Function (PCSCF), or a Serving Call Session Control Function (SCSCF) (358), and the ESBC (356) forwards the traffic to an Internet Protocol Multimedia Subsystem (IMS) (106) core network, the IMS (106) core network being a common IMS architecture deployed within an operator environment.

11. The method of claim 9 , wherein at least one of the SIP trunking code or the IP centric / centrex code is determined based on an area code associated with the short code dialed by the first user.

12. 10. The method of claim 9, wherein the call originates from an Enterprise Session Border Controller (ESBC) (356), and the network device (102) maintains all number configurations associated with SIP trunks, Centrex / IP Centrex, and respective Closed User Group (CUG) definitions.

13. 10. The method of claim 9, further comprising: fusing, by the processor, a plurality of second user devices with a single main number, the main number being associated with the same location, the same authorized signatory, and the same billing identity.

14. 10. The method of claim 9, further comprising: sending, by the processor (202), a credit control request (CCR) to an online charging server (OCS) (410); and receiving a credit control answer (CCA) from the OCS (410) upon executing at least one of the ENUM and the MNP for the URI and after a SIP INVITE for the second user associated with at least one of the first user device (110) and the second user device (110).

15. Upon receiving the CCA from the OCS (410), sending a Location Information Request (LIR) by the processor (202) via an SCSCF (358) to an Interconnect Border Control Function (IBCF) (316) associated with at least one of the first user device (110) and the second user device (110) of the first user, regarding first user information; receiving, by the processor (202) via an Interrogation Call Session Control Function (ICSCF) (362), a Location Information Answer (LIA) from the IBCF (316) associated with at least one of the first user device (110) and the second user device (110) of the first user, along with the first user information; 15. The method of claim 14, further comprising:

16. 10. The method of claim 9, wherein the first user device (110) corresponds to a central exchange (Centrex) / Internet Protocol (IP) Centrex user device and the second user device (110) corresponds to a Session Initiation Protocol (SIP) trunking user device.

17. A user equipment (110) for a general purpose central exchange, comprising: a processor coupled to the processor (202) of the network device (102); a memory coupled to the processor, the memory including processor-executable instructions that, when executed, cause the user device (110) to: transmitting a short code dialed by a first user associated with said user equipment (110) to a second user associated with second user equipment, said second user equipment being communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) (504); receiving a Caller Ringback Tone (CRBT) (406); processing a call between the first user and the second user; The user equipment (110) performs the above.

18. A non-transitory computer-readable medium containing processor-executable instructions, the processor-executable instructions causing a processor to: receiving a short code dialed by a first user from at least one of a first user device (110) to a second user device (110), a second user device (110) to the second user device (110), and an inter-circle / intra-circle first user device (110), wherein the second user device (110) is communicatively coupled to one or more Internet Protocol Private Branch Exchanges (IP PBXs) (504); determining whether the received short code is at least one of a Session Initiation Protocol (SIP) Trunking code or an Internet Protocol (IP) Centrix / Centrex code; Based on the determination, converting the received short code into an associated Uniform Resource Identifier (URI) corresponding to the at least one of the SIP trunking code or the IP Centrix / Centrex code, wherein the short code corresponds to at least one of a fixed line number and a mobile phone number; performing at least one of E.164 number to URI mapping (ENUM) and mobile number portability (MNP) on the URI; sending a SIP INVITE request to invite a second user to associate with at least one of the first user devices (110) for a session, the SIP INVITE including a URI address along with a domain name associated with the second user; sending a caller ringback tone (CRBT) (406) to the first user while, upon receiving a SIP INVITE response from the second user, placing a call to the second user associated with at least one of the first user device (110) and the second user device (110); processing the call between the first user and the second user based on making a call to the second user associated with at least one of the first user device (110) and the second user device (110) and then receiving the call by the second user; A non-transitory computer-readable medium for causing

Images