WO2006015013A2 - Procede et dispositif pour etendre des services ip pbx a des dispositifs de communication cellulaires sans fil - Google Patents

Procede et dispositif pour etendre des services ip pbx a des dispositifs de communication cellulaires sans fil Download PDF

Info

Publication number
WO2006015013A2
WO2006015013A2 PCT/US2005/026583 US2005026583W WO2006015013A2 WO 2006015013 A2 WO2006015013 A2 WO 2006015013A2 US 2005026583 W US2005026583 W US 2005026583W WO 2006015013 A2 WO2006015013 A2 WO 2006015013A2
Authority
WO
WIPO (PCT)
Prior art keywords
call
wcd
pbx
cellular
server
Prior art date
Application number
PCT/US2005/026583
Other languages
English (en)
Other versions
WO2006015013A3 (fr
Inventor
Von K. Mcconnell
Jeffrey F. Phillips
Dorene G. Weiland
Charles E. Woodson
Farni Weaver
Lyle W. Paczkowski
Pallavur Sankaranaraynan
Jack E. Brown
Mark R. Bales
Original Assignee
Sprint Spectrum, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/902,323 external-priority patent/US7406330B2/en
Priority claimed from US11/136,116 external-priority patent/US8060135B2/en
Priority claimed from US11/135,899 external-priority patent/US7260384B2/en
Priority claimed from US11/135,946 external-priority patent/US8254989B2/en
Priority claimed from US11/135,875 external-priority patent/US8064951B2/en
Priority claimed from US11/135,973 external-priority patent/US8180393B2/en
Application filed by Sprint Spectrum, L.P. filed Critical Sprint Spectrum, L.P.
Publication of WO2006015013A2 publication Critical patent/WO2006015013A2/fr
Publication of WO2006015013A3 publication Critical patent/WO2006015013A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/1026—Media gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/10—Aspects of automatic or semi-automatic exchanges related to the purpose or context of the telephonic communication
    • H04M2203/1091—Fixed mobile conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
    • H04M2207/35—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H04M3/4234—Remote access to features of PBX or home telephone systems-teleworking in a PBX
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13098—Mobile subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1322—PBX
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

Definitions

  • the present invention relates to telecommunications and, more particularly, to cellular wireless communications and private branch exchange communications.
  • PBX Private branch exchange
  • PSTN public switched telephone network
  • each telephone station will have an assigned PBX extension number, and some of the stations may also have direct inbound dial (DID) numbers for receiving calls directly from the PSTN.
  • DID direct inbound dial
  • the PBX server may then provide its stations with many useful features, such as the ability to dial by extension, the ability to transfer calls, the ability to establish conference calls, and the ability to interact with an enterprise voice mail service.
  • IP PBX server Traditional PBX servers connect with each of their served telephone stations by a respective physical telephone line, which can be inefficient and difficult to manage.
  • IP PBX server typically, an IP PBX server sits as a node on an enterprise's computer network (e.g., LAN), and each of the enterprise telephone stations in turn sits as a respective node on the computer network as well. Signaling and bearer communications between the telephone stations and the IP PBX server then traverse the computer network as IP communications.
  • the IP PBX server may be coupled to a telephone company central office, so that the enterprise telephone stations can place and receive calls via the PSTN.
  • An enterprise IP PBX system provides great convenience for users of desktop telephone stations at the enterprise. Increasingly, however, people are often working from home or otherwise on the road, rather than at the office. As such, people frequently use cellular wireless communication devices (WCDs), such as cell phones, rather than their desktop enterprise telephone stations. WCDs place and receive calls through cellular radio access networks, rather than through an IP PBX system. Thus, when on the road, an enterprise worker would not benefit from the features of the enterprise IP PBX system (other than by dialing into the IP PBX system through a DID telephone number.)
  • WCDs wireless communication devices
  • an IP PBX system that serves enterprise telephones via a landline IP network connection will be expanded to serve cellular wireless communication devices (WCD) via a cellular wireless carrier's radio access network (RAN).
  • WCD cellular wireless communication devices
  • RAN radio access network
  • a signaling and bearer path infrastructure will be placed between the cellular carrier's RAN and the IP PBX system. Calls to and from the cellular WCD will then be connected through the IP PBX system, so that the IP PBX system can control and manage the calls just as the IP PBX would control and manage calls involving other extensions on the IP PBX.
  • the invention will thus allow a cellular WCD to become an IP PBX client station, i.e., an extension on an off-the-shelf IP PBX server.
  • the cellular WCD will seamlessly benefit from many of the same IP PBX features that other more conventional IP PBX client stations would enjoy.
  • the cellular WCD could seamlessly benefit from these features anywhere within coverage of the cellular carrier's network.
  • the cellular WCD would have an assigned PBX extension number and would thus be able to receive inside-calls placed to that extension number from other stations in the IP PBX system.
  • the cellular WCD would be able to place inside-calls to other stations in the IP PBX system by dialing their extension numbers.
  • the cellular WCD would ideally maintain a public directory number and could thus receive outside calls placed to that directory number and place outside calls from that directory number.
  • the cellular WCD would ideally be able to transfer an existing call to another extension in the IP PBX system and set up conference calls with other extensions in the IP PBX system.
  • the cellular WCD would ideally benefit from a voice mail system associated with the IP PBX system, so that unanswered calls to the cellular WCD could be forwarded to the voice mail system, and a user of the cellular WCD could readily access the voice mail system to listen to messages.
  • the cellular WCD would ideally be able to dial IP PBX feature codes to access various features of the IP PBX system. Still other examples, and variations on these examples, are possible as well.
  • an IP PBX system that serves enterprise telephones via a landline IP network connection can be expanded to serve cellular wireless communication devices (WCD) via a cellular wireless carrier's radio access network (RAN).
  • WCD cellular wireless communication devices
  • RAN radio access network
  • a signaling and bearer path infrastructure will be placed between the cellular carrier's RAN and the IP PBX system. Calls to and from the cellular WCD can then be selectively connected through the IP PBX system, so that the IP PBX system can control and manage the calls just as the IP PBX would control and manage calls involving other extensions on the IP PBX.
  • a cellular WCD can thus become an IP PBX client station, i.e., an extension on an off-the-shelf IP PBX server.
  • the cellular WCD would seamlessly benefit from many of the same IP PBX features that other more conventional IP PBX client stations would enjoy. Further, the cellular WCD would seamlessly benefit from these features anywhere within coverage of the cellular carrier's network.
  • the cellular WCD can have an assigned PBX extension number and can thus receive inside-calls placed to that extension number from other stations in the IP PBX system and place inside-calls to other stations in the IP PBX system by dialing their extension numbers.
  • the cellular WCD can ideally transfer an existing call to another extension in the IP PBX system and set up conference calls with other extensions in the IP PBX system.
  • the cellular WCD can ideally benefit from a voice mail system associated with the IP PBX system, so that unanswered calls to the cellular WCD can be forwarded to the voice mail system, and a user of the cellular WCD can readily access the voice mail system to listen to messages.
  • the cellular WCD can ideally dial IP PBX feature codes to access various features of the EP PBX system.
  • the cellular WCD would ideally maintain a public directory number and could thus receive outside calls placed to that directory number and place outside calls from that directory number. Further, as a client device served by a cellular carrier, the cellular WCD would ideally benefit from another voice mail system associated with the cellular carrier, so that unanswered calls to the cellular WCD could alternatively be forwarded to the cellular carrier's voice mail system. And still similarly, the cellular WCD would ideally be able to dial feature codes and invoke other features that are specific to the cellular carrier's system.
  • a user e.g., end-user or system administrator
  • location of the WCD can be used as a basis to determine whether to apply the cellular-PBX integration function, such as by restricting operation of the cellular-PBX integration function to when the WCD is in a home zone or other designated location.
  • an account-balance limitation can be imposed on application of the cellular-PBX integration function, such as by limiting a given WCD to using the function for only a certain number of minutes per month for instance.
  • a method and system can be applied to determine dynamically ⁇ which of cellular WCD's voice mail systems should be applied in a given instance, that is, whether to apply the WCD's "enterprise” (PBX-based) voice mail system and when to apply the user's the WCD's "personal” (cellular-carrier based) voice mail system.
  • PBX-based personal
  • cellular-carrier based cellular-carrier based
  • an interactive voice response unit IVRU
  • calls could be routed to the WCD's enterprise voice mail system when the cellular-PBX integration function is turned on for the WCD and to the WCD's personal voice mail system when the cellular-PBX integration function is turned off for the WCD.
  • a method and system can be applied to facilitate differential billing, so as to cause a cellular carrier to bill cellular-PBX integration calls to an enterprise while billing traditional cellular calls to the WCD account holder.
  • Figure 1 is a block diagram of a prior art cellular wireless communication system.
  • FIG. 2 is a block diagram of a prior art IP PBX system.
  • Figure 3 is a block diagram of an example network arrangement for integrating an IP PBX system and cellular wireless communication system.
  • Figure 4 is a block diagram depicting exemplary signaling and bearer path infrastructure between a carrier's RAN and an IP PBX server.
  • Figure 5 is a block diagram depicting a network arrangement providing the exemplary signaling and bearer path infrastructure between the RAN and the IP PBX server.
  • Figure 6 is a block diagram like Figure 3, further depicting a provisioning system for configuring entities of the network.
  • Figure 7 is a block diagram of an example network arrangement through which a cellular carrier can provide support for WCD extensions of multiple IP PBX systems.
  • Figure 8 is a block diagram of another example network arrangement through which a cellular carrier can provide support for WCD extensions of multiple IP PBX systems.
  • Figures 9-12 are message flow diagrams depicting call setup signaling in accordance with an exemplary embodiment of the invention.
  • Figure 13 is a block diagram of an example network arrangement including master IP PBX servers and enterprise IP PBX servers, in accordance with the exemplary embodiment.
  • Figure 14 is a block diagram of another example network arrangement including master IP PBX servers and enterprise IP PBX servers, in accordance with the exemplary embodiment.
  • Figures 15-21 are flow charts depicting functions that can be carried in accordance with exemplary enhancements of cellular-PBX integration service.
  • Figure 1 is a block diagram depicting the arrangement of a basic cellular wireless communication system
  • Figure 2 is a block diagram depicting the arrangement of a basic IP PBX system. It should be understood, of course, that these are merely examples and that other arrangements of cellular wireless systems and IP PBX systems are equally possible. a. Cellular Wireless Communication System
  • a typical cellular wireless communication system includes at its core a radio access network (RAN) 12, which serves one or more wireless communication devices, such as WCD 14 for instance.
  • the RAN 12 includes a base transceiver station (BTS) 16, which radiates to define an air interface 18 through which WCD 14 can communicate, and a base station controller (BSC) 20 that manages air interface communications.
  • BTS base transceiver station
  • BSC base station controller
  • the RAN includes a mobile switching center (MSC) 22 or other switching point that provides connectivity with the PSTN 24.
  • MSC mobile switching center
  • MSC 22 is coupled with an out of band signaling network, represented in Figure 1 by signal transfer point (STP) 26, through which MSC 22 can engage in signaling to set up calls, to obtain call processing guidance, to acquire profile logic for the WCDs that it serves.
  • STP signal transfer point
  • MSC 22 may conventionally engage in SS7 (Integrated Services Digital Network (ISDN) User Part, or "ISUP") signaling via STP 26 with a remote switching point (SP) 28 that serves a remote telephone device 30.
  • SP remote switching point
  • MSC 22 may send a query message via STP 26 to a service control point (SCP) 32 or other entity and may then receive a call-handling directive from that entity.
  • SCP service control point
  • MSC 22 may receive a service profile for the WCD from a home location register (HLR) 34, via the STP 26, and MSC 22 may store that profile in a visitor location register (VLR) 36 for reference.
  • HLR home location register
  • VLR visitor location register
  • WCD 14 can place and receive calls over PSTN 24. For instance, to place a call to remote telephone device 30, WCD 14 may send a call origination message over an access channel on air interface 18 to RAN 12, which would provide MSC 22 with dialed digits representing the telephone number of device 30.
  • MSC 22 may then pause call processing and query up to SCP 32 to obtain call processing guidance. For instance, MSC 22 may send an IS-41 "Origination Request" (ORREQ) message via STP 26 to SCP 32, providing SCP 32 with the calling and called telephone numbers and any other pertinent information. SCP 32 may then apply service logic to decide how the call should be handled and send a call handling directive via STP 26 to MSC 22. And MSC may then carry out that directive.
  • ORREQ Resource Order Request
  • MSC 22 would direct BSC 20 to assign an air interface traffic channel over which WCD 14 can communicate. Further, MSC 22 would work to set up a call path to the called device 30, typically by engaging in SS7 ISUP signaling. For instance, MSC 22 may first send an ISUP "Initial Address Message” (IAM) via STP 26 to SP 28. SP 28 would then reserve a trunk for the call and send an ISUP "Address Complete Message” (ACM) via STP 26 to MSC 22, indicating the port/trunk reserved. MSC 22 would then connect the call through to that trunk and send a ringing tone to the calling WCD 14. When the called party answers (goes off hook), SP 28 would in turn send an ISUP "Answer Message” (ANM) to the MSC to complete call setup, and the call would then commence.
  • IAM ISUP "Initial Address Message”
  • ACM ISUP "Address Complete Message”
  • MSC 22 may query SCP 32 for call processing guidance, and, assuming the call should go through, MSC 22 may page WCD 14 over a paging channel on air interface 18 and may direct BSC 20 to assign a traffic channel through which WCD 14 can communicate.
  • MSC 22 may signal back to SP 26 to complete setup of a call path through PSTN 24, so that the call can commence.
  • MSC 22 may be coupled by a voice trunk with a voice mail server (VMS) 37.
  • VMS voice mail server
  • MSC 22 may route the call to VMS 37 for handling in a manner well known in the art.
  • FIG. 1 depicts another feature commonly found in most cellular wireless systems, namely, a mobile positioning center (MPC) 39.
  • MPC 39 which is conventionally coupled with STP 26, functions to determine the location of a WCD and to store and report that location, in order to facilitate various location-based services such as 9- 1-1 call-handling for instance.
  • MPC 39 receives a request for a WCD's location and then responsively invoke a process well known in the art to determine the location (if not already known). For instance, MPC 39 or an associated position determining entity may engage in signaling (via MSC 22) with the WCD 14, to obtain a granular GPS location reading.
  • MPC 39 may simply engage in signaling with MSC 22 or HLR 34 to determine the cell or cell sector in which the WCD is currently operating (or was last registered). MPC 39 can determine a WCD's location in other ways as well. As shown, MPC 39 may be coupled with a packet-switched network 41, through which MPC 39 may receive and respond to location-requests. b. IP PBX System
  • a typical IP PBX system includes at its core an IP PBX server 40, such as one manufactured by Avaya Inc. (e.g., the "Communications Manager” platform), Cisco Systems, Inc. (e.g., the “Avid” platform), Nortel Networks, Ltd. (e.g., the “MCS” platform), or 3Com Corporation (e.g., the "NBX” platform), for instance.
  • the EP PBX server 40 normally sits as a node on a packet-switched network 42, which typically comprises an enterprise local area network (LAN) but could take other forms as well.
  • LAN enterprise local area network
  • Communicatively linked with the packet-switched network are then multiple end-user telephone stations, represented in Figure 2 by devices 44, 46, 48, each of which may have an extension defined by D? PBX server 40.
  • Each of these telephone stations may be a voice over IP (VoIP) telephony device (such as an IP telephone, ⁇ P fax machine, multi-media computer, media terminal adapter, analog terminal adapter, or other device) that is capable of engaging in packetized bearer and signaling communication with the IP PBX server 40 so as to communicate real time media such as voice, video or audio, or other data or information (e.g., fax or modem data) that is normally carried over a telephone line.
  • VoIP voice over IP
  • the enterprise voice mail server 62 may be integrated as a function of the IP PBX server 40 or, as shown, may exist as a separate component.
  • IP PBX server 40 is coupled via one or more Tl lines, PRI lines, or other high capacity circuit link 50 with a local telephone company central office (CO) 52, which provides connectivity with the PSTN 54.
  • CO local telephone company central office
  • the link between E? PBX server 40 and CO 52 may carry multiple subscriber (local loop) telephone lines, each providing a direct dial line for the enterprise.
  • subscriber local loop
  • the enterprise telephone stations can place and receive calls over the PSTN.
  • IP PBX server 40 normally includes or has access to configuration data (not shown) for each of the enterprise telephone stations that it serves.
  • the configuration data defines a PBX extension and other service parameters and preferences, such as preferences to have unanswered calls forwarded to the enterprise voice mail server 62, and the like.
  • the configuration data may correlate DID numbers with certain stations, so as to allow PSTN calls to be placed directly to those stations (rather than being placed to a main IP PBX number and from there being transferred to the stations).
  • One or more computer terminals sitting on the network 42 or coupled directly with IP PBX server may be used to provision the configuration data for the various telephone stations.
  • an administrator terminal 60 may run a provisioning program or provide access to a web-based provisioning program, through which an administrator can set up and manage IP PBX configuration parameters for the various telephone stations.
  • the enterprise telephone devices will engage in signaling communication with the IP PBX server 40 using a proprietary or standard signaling protocol to set up and manage calls.
  • suitable protocols include H.323 and Session Initiation Protocol (SIP), each of which are well known.
  • SIP Session Initiation Protocol
  • an enterprise telephone station could send an IP-based SIP "INVITE" message to the IP PBX server 40, in an effort to set up a call to another extension on the IP PBX server or a call to an outside telephone number.
  • the IP PBX server 40 may then send a SIP INVITE in turn to the called station, to cause the station to ring.
  • the called station may respond to the IP PBX server 40 with a SIP "200 OK" message, and the IP PBX server 40 may in turn respond to the calling station with a SIP 200 OK message.
  • a VoIP e.g., Real-time Transport Protocol
  • a VoIP would be set up between the calling and called stations, so that users of the stations can communicate with each other.
  • the IP PBX server 40 may forward (or allow pass-through of) the digits dialed by the calling station, via link 50, to CO 52, and CO 52 may set up the call over PSTN 54 to the called party.
  • IP PBX server 40 During an ongoing call that an enterprise telephone station establishes through IP PBX server 40, a signaling path remains between the enterprise telephone station and the IP PBX server 40. Further, in some cases (such as with outside calls), the bearer path of the call also passes through the IP PBX server 40. Consequently, during an ongoing call, a user of the enterprise telephone station can invoke IP PBX functions, such as call transfer, conference calling, or the like.
  • an IP PBX server 40 will sit as a node on one or more IP networks.
  • the IP PBX server will sit as a node on an enterprise LAN and will be located physically at the enterprise premises.
  • the enterprise will typically buy or lease the IP PBX server 40 and will manage operation of the server.
  • this can be a burden for the enterprise.
  • the IP PBX server 40 can be physically hosted and managed by a telecom carrier or other entity outside of the enterprise and can be coupled by a packet-data connection with the enterprise network. That way, the outside entity can provide EP PBX service for the enterprise, while relieving the enterprise of much of the responsibility for acquiring and managing an EP PBX server of its own.
  • the network cloud 42 shown in Figure 2 between the EP PBX server and the enterprise telephone stations may include both the enterprise network and one or more external EP networks or other communication links, such as the Internet and a telecom carrier's core packet-data network for instance.
  • the IP PBX server 40 may maintain configuration data for each of the enterprise telephone stations and may engage in signaling communication (e.g., SIP or H.323) with the enterprise telephone stations to set up and manage both inside and outside calls. Further, an administrator terminal 60 located at the enterprise network or elsewhere could be arranged to provision configuration data on the IP PBX server 42.
  • an IP PBX system that serves enterprise telephone stations will be expanded to serve cellular wireless communication devices via a conventional cellular RAN.
  • a signaling and bearer path infrastructure will be placed between the cellular carrier's RAN and the IP PBX system. Calls to and from cellular WCDs will then be connected through the IP PBX system (or at least with signaling passing through the IP PBX system), so that the IP PBX system can control and manage the calls just as the IP PBX system would control and manage calls involving other extensions on the IP PBX.
  • Figures 3-5 are simplified block diagrams depicting example network arrangements for integrating an IP PBX system and a cellular wireless communication system in this manner. It should be understood, however, that other arrangements are possible as well.
  • the network arrangement includes a media gateway system 70 that provides signaling and bearer path communications between a cellular carrier's RAN 12 and an IP PBX server 40.
  • the media gateway system ' 70 includes a media gateway (MGW) 72, which converts between bearer data formats used in the PSTN (such as a pulse code modulated (PCM) format or another time division multiplex (TDM) format) and bearer data formats used for IP-based communication (such as a Real-time Transport Protocol (RTP) format).
  • MGW media gateway
  • the media gateway system 70 includes a media gateway controller (MGC) 74, which converts between signaling formats used to set up and manage calls in the PSTN (such as SS7 signaling) and signaling formats used to set up and manage calls over IP (such as SIP or H.323).
  • MGW 72 and MGC 74 can be integrated together or can be distributed, and they can be programmed to communicate with each other through an accepted gateway control protocol such as H.248 or Media Gateway Control Protocol (MGCP) for instance.
  • MGCP Media Gateway Control Protocol
  • Media gateway system 70 can take other forms as well. For instance, it could comprise a Parlay gateway or other entity that translates between legacy circuit-switched communications (e.g., SS7 signaling and TDM bearer traffic) and next generation (packet- switched) communications (e.g., SIP or H.323 signaling and RTP bearer traffic)).
  • legacy circuit-switched communications e.g., SS7 signaling and TDM bearer traffic
  • next generation (packet- switched) communications e.g., SIP or H.323 signaling and RTP bearer traffic
  • a bearer communication path extends between MSC 22 and IP PBX server 40 via MGW 72.
  • a circuit link 76 such as a PSTN voice trunk extends between MSC 22 and MGW 72
  • a packet-link 78 such as an Ethernet line or packet- switched network extends between MGW 72 and IP PBX server 40.
  • Bearer telephony traffic may therefore flow between MSC 22 and MGW 72 as PCM data or in any other form(s) in which bearer telephony traffic can flow between MSC 22 and another switching point on the PSTN.
  • bearer telephony traffic may flow between MGW 72 and IP PBX server 40 as RTP/TP data or in any other form(s) in which bearer telephony traffic can flow over a packet- switched network.
  • MGW 72 would then operate to convert between these forms of bearer traffic so as to allow end-to-end bearer communication between the MSC 22 and the IP PBX server 40.
  • a signaling path extends between MSC 22 and IP PBX server 40.
  • an SS7 signaling path extends between MSC 22 and MGC 74 via STP 26, just as an SS7 signaling path would normally extend between MSC 22 and another PSTN switching point via STP 26.
  • an IP -based signaling path such as an Ethernet link or packet- switched network extends between MGC 74 and IP PBX server 40.
  • SS7 signaling traffic may then flow between MSC 22 and MGC 74, and IP -based signaling traffic, such as SIP or H.323 traffic, may flow between MGC 74 and IP PBX server 40.
  • MGC 74 would operate to convert between these forms of signaling traffic so as to allow end-to-end signaling communication between MSC 22 and IP PBX server 40.
  • MGC 74 could send SS7 signaling messages over IP to MGW 72, and MGW 72 could then transpose those messages from an IP format into an SS7 format and send them along to STP 26.
  • STP 26 could route SS7 signaling messages to MGW 72, and MGW could convert those messages to an IP format and could send them to MGC 74.
  • IP PBX server 40 may include or be connected with a media server (or, more generally, a media server function), to facilitate engaging in RTP or other bearer communication with MSC 22, via MGW 72.
  • a media server or, more generally, a media server function
  • MSC 22 via MGW 72.
  • the media server could be an Avaya G600 media server.
  • the D? PBX server and media server can be separately coupled with the MGC 74, or they may have a common packet-data link (e.g., a common network or router connection) with the MGC 74.
  • the wireless carrier that owns and operates RAN 12 will position MGW 72 at the same physical site 80 as the MSC 22, so as to facilitate easy shunting of calls between the MSC 22 and the MGW 72.
  • a carrier that operates many MSCs may position a respective MGW 72 at each MSC site.
  • the carrier may position the MGC 74 as a node on its core signaling network, so as to facilitate SS7 signaling between the MSC 22 and the MGC 74.
  • the carrier may connect the MGW 72 by an inter- machine trunk (IMT) or primary rate interface (PRI) line to a switch port of MSC 22.
  • IMT inter- machine trunk
  • PRI primary rate interface
  • the carrier may couple the MGW 72 with a packet-data connection (e.g., Ethernet link, carrier's core packet network, Internet, etc.) to the MGC 74, to facilitate H.248, MGCP or other signaling between the MGW 72 and the MGC 74.
  • the carrier may couple the MGC 74 with a similar packet-data connection to the IP PBX server 40, to facilitate IP- based signaling communication between the MGC 74 and the IP PBX server 40.
  • the carrier would couple the MGW 72 with a packet-data connection to the IP PBX server 40 (and/or media server), to facilitate bearer communication between the MGW 72 and the IP PBX server 40.
  • an IP PBX server 40 can sit on the enterprise network or can be hosted outside of the enterprise. (As will be described below, an IP PBX system 40 can alternatively comprise both an IP PBX server on the enterprise network and an IP PBX server outside of the enterprise network.)
  • the packet-data connection between the MGW 72 and the IP PBX server 40 could include the carrier's core packet network and the Internet or other link
  • the packet-data connection between the MGC 74 and the IP PBX server 40 could similarly include the carrier's core packet network and the Internet or other link.
  • the enterprise network would provide packet-data connectivity between the IP PBX server 40 and the enterprise telephone stations.
  • IP PBX server 40 In the scenario where the IP PBX server 40 is hosted outside of the enterprise network, such as on the carrier's core packet network for instance, the packet-data connections between the MGW 72 and the IP PBX server 40 and between the MGC 74 and the IP PBX server 40 could similarly be the carrier's core network or could take some other form. Further, the carrier would couple IP PBX server 40 with a packet-data connection (including, for instance, the carrier's core network and the Internet) to the enterprise network, so that the IP PBX server 40 can engage in IP-based signaling and bearer communication with the enterprise telephone stations and/or other entities on the enterprise network.
  • IMS IP Multimedia Subsystem
  • the signaling path between MGC 74 and IP PBX server 40 can advantageously include a call session control function (CSCF) 100.
  • CSCF call session control function
  • the exemplary signaling and bearer path infrastructure between the cellular carrier's RAN 12 and the IP PBX server 40 includes both the media gateway system 70 and a CSCF 100.
  • CSCF 100 beneficially serves as a trigger point to invoke various policy logic when setting up a communication in the integrated cellular-PBX system.
  • CSCF 100 preferably includes or has access to a subscriber profile store such as a home subscriber server (HSS) 102, which contains profile data for subscribers to the inventive service.
  • HSS home subscriber server
  • CSCF 100 further includes or has a communication link with various policy servers 104, which contain policy logic for determining how to handle particular communication setup requests and the like.
  • CSCF 100 is then coupled with IP PBX server 40, so as to facilitate signaling with the IP PBX server.
  • CSCF 100 is coupled with one or more voice mail servers 106, so as to facilitate signaling with the voice mail server(s).
  • MGC 74 functions to pass session setup and control signaling between STP 26 (e.g., as SS7 signaling) and CSCF 100 (e.g., as SIP signaling).
  • MGW 72 in coordination with MGC 74, functions to pass bearer traffic between MSC 22 (e.g., as PCM data) and IP PBX server 40 (e.g., as RTP data) or voice mail server(s) (also e.g., as RTP data).
  • Figure 5 next depicts more specifically a preferred network arrangement providing the exemplary signaling and bearer path infrastructure between RAN 12 and IP PBX server 40.
  • one or more packet-switched networks cooperatively shown as network cloud 130, sits between media gateway system 70 and IP PBX server 40.
  • CSCF 100 Sitting as nodes on network 130, in addition to the MGW 72, MGC 74, and IP PBX server 40, are CSCF 100, HSS 102, policy servers 104, and voice mail server(s) 106.
  • MPC 39 to be used for location-determination
  • an ENUM and/or DNS server 132 to be used to facilitate routing of IP traffic.
  • policy servers 104 include a personal-enterprise (PE) policy server 136, a location policy server 138, a voice mail policy server 140, and an account balance policy server 142.
  • PE personal-enterprise
  • These policy servers can be embodied as discrete server cards and can all be housed together in a chassis, such as an IBM Blade Server, for instance, each with its own IP address.
  • the policy servers could be embodied as server functions in the form of program logic modules all executable by one or more common processors.
  • CSCF 100 is programmed to reference, query, and/or route signaling messages (such as SIP messages) through these or other policy servers.
  • a bearer communication path extends between MSC 22 and IP PBX server 40 via MGW 72.
  • a circuit link such as a PSTN voice trunk extends between MSC 22 and MGW 72
  • a packet-link such as an Ethernet line or packet-switched network extends between MGW 72 and IP PBX server 40.
  • Bearer telephony traffic may therefore flow between MSC 22 and MGW 72 as PCM data or in any other form(s) in which bearer telephony traffic can flow between MSC 22 and another switching point on the PSTN.
  • bearer telephony traffic may flow between MGW 72 and IP PBX server 40 as RTP/IP data or in any other form(s) in which bearer telephony traffic can flow over a packet-switched network.
  • MGW 72 would then operate to convert between these forms of bearer traffic so as to allow end-to-end bearer communication between the MSC 22 and the IP PBX server 40.
  • a signaling path extends between MSC 22 and IP PBX server 40 via MGC 74 and CSCF 100.
  • an SS7 signaling path extends between MSC 22 and MGC 74 via STP 26, just as an SS7 signaling path would normally extend between MSC 22 and another PSTN switching point via STP 26.
  • An IP-based signaling path such as an Ethernet link or packet-switched network extends between MGC 74 and CSCF 100. Similarly, an IP- based signaling path also extends between CSCF 100 and IP PBX server 40. SS7 signaling traffic may then flow between MSC 22 and MGC 74, and IP -based signaling traffic, such as SIP or H.323 traffic, may flow between MGC 74 and IP PBX server 40 via CSCF 100. MGC 74 would operate to convert between these forms of signaling traffic so as to allow end-to- end signaling communication between MSC 22 and IP PBX server 40.
  • an IP PBX server 40 can sit on the enterprise network or can be hosted outside of the enterprise, hi the scenario where the IP PBX server 40 resides on the enterprise network, the packet-data connection between the MGW 72 and the IP PBX server 40 could include the carrier's core packet network and the Internet or other link, and the packet-data connection between the CSCF 100 and the IP PBX server 40 could similarly include the carrier's core packet network and the Internet or other link. Further, the enterprise network would provide packet-data connectivity between the IP PBX server 40 and the enterprise telephone stations.
  • the packet-data connections between the MGW 72 and the IP PBX server 40 and between the CSCF 100 and the IP PBX server 40 could similarly be the carrier's core network or could take some other form.
  • the carrier would couple IP PBX server 40 with a packet-data connection (including, for instance, the carrier's core network and the Internet) to the enterprise network, so that the IP PBX server 40 can engage in IP-based signaling and bearer communication with the enterprise telephone stations and/or other entities on the enterprise network.
  • each entity may include or have access to one or more processors (e.g., general purpose and/or special purpose processors), one or more data storage elements (e.g., volatile and/or non-volatile storage), and one or more communication interfaces (e.g., Ethernet network interface modules, or other interfaces) to facilitate communication over the various links shown.
  • the data storage of each entity may include reference data and/or program instructions (e.g., machine language instructions) executable to carry " out various functions described herein/
  • the entities can include hardware or firmware, or any combination of hardware, firmware, and/or software, to carry out the various functions.
  • HLR 34 may include or have access to a profile record or other service logic for WCD 14.
  • the profile record or other service logic may define wireless intelligent network (WIN) trigger logic for causing MSC 22 to query SCP 32 for call processing guidance when MSC 22 is faced with a request to set up a call for WCD 14.
  • WIN wireless intelligent network
  • HLR 34 would send such logic to MSC 22 (e.g., in an IS-41 registration notification response or qualification directive) for storage in VLR 36, when WCD 14 registers in the service area of MSC 22, when the logic in HLR 34 gets updated, or at other times.
  • SCP 32 may similarly include or have access to a profile record or other service logic for WCD 14.
  • the profile record may include an indication of whether the WCD subscribes to cellular-PBX integration service, and whether the service is currently active or inactive for the WCD, that is, whether or not the service is to be applied for the WCD.
  • the profile record or other service logic in SCP 32 may thus indicate that, when MSC 22 is faced with a request to set up a call for WCD 14, MSC 22 should set up the call to media gateway system 70, i.e., by engaging in SS7 signaling with MGC 74.
  • the logic in SCP 32 may also indicate that, if a call to WCD 14 has already been routed to IP PBX server 40 and back to MSC 22, the call should not again be routed to IP PBX server 40 (to avoid endless looping).
  • Media gateway system 70 may similarly include or have access to a profile record or other logic for WCD 14.
  • the profile record or other logic would include routing logic or other correlation data that correlates WCD 14 with IP PBX server 40 or that otherwise indicates that IP PBX server 40 serves WCD 14. That way, when MGC 74 is faced with a request to set up a call to or from WCD 14, MGC 74 could refer to that correlation data and thereby determine (based on an identifier of WCD 14 provided in the request) that the call should be set up to IP PBX server 40.
  • the correlation data can correlate (i) a WCD identifier (e.g., mobile identification number, mobile directory number, electronic serial number, etc.) that would be provided in the call setup signaling from MSC 22 with (ii) a network address (e.g., SIP address, IP address, network access identifier, etc.) of IP PBX server 40 to which MGC 74 can send call setup signaling.
  • a WCD identifier e.g., mobile identification number, mobile directory number, electronic serial number, etc.
  • a network address e.g., SIP address, IP address, network access identifier, etc.
  • HSS 102 may include a profile record or other logic for WCD 14.
  • a profile record can similarly include routing logic or other correlation data that correlates WCD 14 with IP PBX server 40 or otherwise indicates that IP PBX server 40 serves WCD 14.
  • the profile record can include data that facilitate application of various policies by CSCF 100 and/or by policy servers 104.
  • the profile record for WCD 14 in HSS 102 may also include an indication of whether the WCD subscribes to cellular-PBX integration service, and whether the service is currently active or inactive for the WCD.
  • the profile record or other service logic in the HSS 102 may indicate that, when CSCF 100 is faced with a request to set up a call for a WCD 14, the CSCF should route call setup signaling to one or more entities, such as to one or more of the policy servers 104 for instance.
  • the CSCF 100 may obtain from HSS 102 a particular domain name of a policy server and may then dip into a DNS server to resolve that domain name into a routable IP address and then send the INVITE (or a corresponding INVITE) to that IP address. Further, upon receipt of such a signaling message, the policy server itself may dip into the HSS 102 to obtain service logic parameters for the calling party or called party. The policy server may then further modify or reform the signaling message and pass it back or along to CSCF 100, which may then carry out a designated service policy, such as routing the signaling message to a particular destination.
  • a designated service policy such as routing the signaling message to a particular destination.
  • IP PBX server 40 may include or have access to profile data or service logic for WCD 14.
  • the profile data or service logic of EP PBX server 40 would define configuration data for WCD 14, which would assign an D? PBX extension number to the WCD 14, and which would correlate the extension number with the directory number (e.g., mobile directory number) of the WCD 14.
  • the configuration data for WCD 14 may define service preferences, such as whether to forward calls to voice mail and the like.
  • B? PBX server 40 can apply those service preferences or other logic as it would for a call being placed to or from any other one of its extensions.
  • the configuration data for WCD 14 may also correlate the extension of WCD 14 with another extension on D? PBX server 40. For instance, if an enterprise user normally uses a particular desk phone when at work (on the enterprise network) but uses WCD 14 when on the road, the configuration data for WCD 14 can correlate the extension of WCD 14 with the extension of the user's desk phone. That way, when IP PBX server 40 is faced with a request to set up a call to or from WCD 14, IP PBX server 40 can pro grammatically set up the call to both WCD 14 and the user's desk phone extension, either simultaneously ringing both phones (and connecting with the one that answers first) or sequentially ringing both phones.
  • the configuration data for WCD 14 will be marked or have a characteristic of some kind that indicates IP PBX server 40 should handle calls for WCD 14 in a special way.
  • the configuration data could be flagged (e.g., by the mere existence of a mobile directory number in the configuration data) to indicate that the WCD 14 is a WCD, and could indicate a network address of the MGC 74 to which call setup signaling can be sent for WCD 14. (This can " advantageously allow a given IP PBX server to extend its service to WCDs served by more than one wireless carrier, or through more than one media gateway system.)
  • the IP PBX server 40 may determine based on the WCD's configuration data that the IP PBX server 40 should simultaneously set up the call to both the WCD 14 (via media gateway system 70 and RAN 12) and to the WCD user's desk phone on the enterprise network.
  • the IP PBX server 40 may determine based on the WCD's configuration data how to handle the call and may handle the call accordingly.
  • FIG. 6 depicts an exemplary provisioning system 90 that may be in place to centrally configure HLR 34, SCP 32, MGC 72, and IP PBX server 40 (as well as any other entities, such as CSCF 100, HSS 102, and policy servers 104, for instance (not shown in Figure 6)) with service settings to facilitate operation of the invention.
  • the provisioning system 90 can include a computer server (such as an "Actiview" server) that sits on the carrier's core network and that is programmed to communicate directly or through one or more other service provisioning interfaces (e.g., service management systems, enhanced service managers, etc.) with the various entities to be provisioned.
  • a computer server such as an "Actiview" server
  • service provisioning interfaces e.g., service management systems, enhanced service managers, etc.
  • the provisioning server would engage in industry standard CORBA signaling to convey provisioning updates to the various entities.
  • the administrator terminal 60 or another user terminal can be communicatively linked with the provisioning system 90 (e.g., through a web interface) so as to allow an administrator or other user to configure EP PBX services for WCD 14. d. Support for Multiple IP PBX Servers
  • the exemplary arrangements generally depicted in Figures 3-5 can be expanded to support multiple IP PBX servers, so that multiple IP PBX systems can serve cellular WCDs via a common cellular carrier.
  • the routing logic or other correlation data used by media gateway system 70 and/or CSCF 100 and policy servers 104 can correlate each of a plurality of WCDs with a respective IP PBX server that serves the WCD (i.e., the D? PBX server on which the WCD is an extension).
  • the MGC 74 may then programmatically reference the correlation data to determine which D?
  • the MGC 74 may then engage in signaling with that EP PBX server in order to set up the call to or through the EP PBX server.
  • the CSCF 100 or a policy server to which it signals may programmatically reference the correlation data to determine which EP PBX server serves the WCD, and the CSCF 100 may then engage in signaling with that EP PBX server in order to set up the call to or through the EP PBX server.
  • Figure 7 depicts an example arrangement for carrying out this function in the system of Figure 3 for instance.
  • the example arrangement includes several WCDs 150, 152, 154 and several IP PBX servers 156, 158, 160, all of which are coupled by a packet-data link (e.g., network) with MGC 74 and with MGW 72.
  • Each IP PBX server is shown coupled by a packet-data network with a plurality of enterprise telephone stations.
  • each IP PBX server may reside on a respective enterprise network, and each enterprise network may have its own respective set of enterprise telephone stations that are extensions on its IP PBX server.
  • each IP PBX server may reside in a carrier's core network and can function as a host IP PBX server for one or more enterprise networks, coupled by packet-data links with the enterprise networks that they serve. Still alternatively, some of the IP PBX servers may reside on enterprise networks and others may be host IP PBX servers that reside on a carrier's network or elsewhere.
  • MGC 74 includes or has access to correlation data (e.g., routing data) 162, which correlates WCDs with IP PBX servers.
  • the correlation data may take the form of a table of data, in which each record has a WCD identifier field and an IP PBX server identifier field.
  • Each WCD identifier can be a WCD directory number (telephone number), a WCD serial number (e.g., ESN), or some other identifier that would be conveyed in SS7 call setup signaling from MSC 22 or that can be derived from such signaling.
  • Each IP PBX serer identifier can be a SIP address, an IP address, a network access identifier, or some other identifier that can be used as a basis to route IP-based call setup signaling messages to the IP PBX server.
  • this data would be provisioned on MGC 74 by provisioning system 90 as depicted in Figure 6.
  • MGC 74 may determine by reference to correlation data 162 that IP PBX server 156 serves the WCD, and so MGC 74 may set up the call to IP PBX server 156 for handling.
  • MGC 74 may determine by reference to correlation data 162 that IP PBX server 158 serves the WCD, and so MGC 74 may set up the call to IP PBX server 158 for handling.
  • HSS 102 could include or have access to similar correlation data that correlates WCDs with IP PBX servers. This arrangement is illustrated in Figure 8.
  • the example arrangement again includes several WCDs 150, 152, 154 and example IP PBX servers 156, 158, 160, with all of the IP PBX servers being coupled with a packet-data network that provides connectivity with CSCF 100, MGW 72, MGC 74, HSS 102, and policy servers 104.
  • Each IP PBX server is shown coupled hy a packet-data network with a plurality of enterprise telephone stations.
  • each IP PBX server may reside on a respective enterprise network, and each enterprise network may have its own respective set of enterprise telephone stations that are extensions on its IP PBX server.
  • each IP PBX server may reside in a carrier's core network and can function as a host IP PBX server for one or more enterprise networks, coupled by packet-data links with the enterprise networks that they serve. Still alternatively, some of the IP PBX servers may reside on enterprise networks and others may be host IP PBX servers that reside on a carrier's network or elsewhere.
  • HSS 102 includes or has access to the correlation data 162 that correlates WCDs with IP PBX servers.
  • this data would be provisioned in HSS 102 by a provisioning system such as that described above.
  • CSCF 100 may dip into HSS 102 and determine by reference to correlation data 162 that IP PBX server 156 serves the WCD, and so CSCF 100 may set up the call to IP PBX server 156 for handling.
  • CSCF 100 may dip into HSS 102 and determine by reference to correlation data 162 that IP PBX server 158 serves the WCD, and so CSCF 100 may set up the call to IP PBX server 158 for handling.
  • a policy server such as the PE policy server 136 (of Figure 5) receives a signaling message from CSCF 100 indicative of a request to set up a call to or from WCD 150
  • the policy server may dip into HSS 102 and determine by reference to correlation data 162 that IP PBX server 156 serves the WCD, and the policy server may responsively provide CSCF 100 with a domain name of IP PBX server 156.
  • CSCF 100 may then set up the call to IP PBX server 156 for handling.
  • the policy server when the policy server receives a signaling message from CSCF 100 indicative of a request to setup a call to or from WCD 152, the policy server may dip into HSS 102 and determine by reference to correlation data 162 that IP PBX server 158 serves the WCD. The policy server may therefore provide the CSCF with the domain name of IP PBX server 158, and the CSCF may set up the call to that IP PBX server for handling.
  • WCD 14 can function as an extension of IP PBX server 40, so as to benefit from many or all of the same IP PBX services that enterprise telephone stations 44, 46, 48 enjoy. Consequently, the enterprise can extend its off the shelf IP PBX system to serve not only traditional IP PBX telephone stations but also mobile WCDs such as WCD 14.
  • a user would enter the extension number and press "SEND" or another key.
  • an origination message will then pass over an air interface from WCD 14 to MSC 22 in the carrier's RAN 12, providing the RAN with (i) the WCD's mobile directory number (MDN) and electronic serial number (ESN) or one or more other identifiers, and (ii) the dialed digits, which, in this case, would be the dialed PBX extension rather than a full directory number.
  • MDN mobile directory number
  • ESN electronic serial number
  • the MSC may then encounter a WIN trigger that points to the SCP.
  • the MSC would send an IS-41 "Origination Request" (ORREQ) message via the signaling network to SCP 32, providing the SCP with the calling and called numbers.
  • SCP 32 may then refer to a subscriber profile store to determine that the WCD originating the call subscribes to IP PBX service.
  • the SCP will send an Origination Request return result (orreqjr) to MSC 22, providing the MSC with the routing number of MGC 74, so as to cause MSC 22 to set up the call to the media gateway system.
  • MSC 22 would then send an ISUP IAM call setup message via the signaling network to MGC 74, providing the MGC with the calling and called numbers, and indicating that the call is a WCD-originated call.
  • Existing call signaling protocols define a parameter that can be used to indicate whether a call is a WCD-originated call (a call from a WCD) or a WCD-terminated call (a call to a WCD), for purposes of allowing a call processing entity to determine which party's profile to reference when setting up the call.
  • the MGC may then dip into correlation data 112 to determine which host IP PBX server serves the originating cellular WCD (e.g., based on its MDN), at step 206.
  • the MGC may thereby get an IP address or SIP address of the applicable IP PBX server, presumably IP PBX server 40, at step 207.
  • MGC 74 may then work on behalf of MGW 72 to set up a voice/RTP call leg between MGW 72 and the selected IP PBX server 40 and a circuit-switched (e.g., PCM) call leg between MSC 22 and the MGW 72.
  • MGC 74 could engage in SIP or H.323 signaling with the host IP PBX server, at step 208, to set up a voice/RTP session between the MGW 72 and the IP PBX server 40, and MGC 74 could engage in further ISUP signaling with MSC 22, at step 210, to set up a circuit call leg between MSC 22 and MGW 72.
  • IP PBX server 40 has thus received a signaling message seeking to set up a call from WCD 14 to another IP PBX extension. Further, the IP PBX server 40 has a communication bearer path with WCD 14, via the RTP leg, MGW 72, the circuit leg, MSC 22, and cellular air interface 18. Thus, IP PBX server 40 can apply the enterprise dial plan and thereby determine that this is a call to one of the enterprise IP PBX extensions.
  • the IP PBX server 40 may then set up the call with SIP and RTP to the enterprise telephone station having that extension, at step 212. For instance, if the IP PBX server 40 sits on the enterprise network, the IP PBX server 40 may engage in SIP communication with the called station to set up an RTP call path between the IP PBX server 40 and the called station.
  • the IP PBX server 40 can similarly engage in SIP communication with the called station, via a packet-data link with the enterprise network, and via the enterprise network, to set up an RTP call path between the IP PBX server 40 and the called station.
  • the IP PBX server 40 can conveniently manage the call, providing IP PBX features such as call transfer, conference calling, and the like for WCD 14.
  • the IP PBX server 40 determines for some reason (such as based on the enterprise dialing plan or the WCD's configuration data) that the call cannot be connected through to the called party, the IP PBX server 40 (or its associated media server) could play a speech or tone announcement to the caller, via the established bearer path. b. Originating Outside Calls
  • WCD 14 places a call to a PSTN phone number, i.e., to a full PSTN number rather than an IP PBX extension, such as the phone number of telephone 30 for instance.
  • the PSTN number could be a DID number in the enterprise, but that does not matter.
  • This scenario is largely the same as the scenario described above, up until the point where a call path (or associated signaling) is established to the IP PBX system, e.g., to the IP PBX server 40, except that the dialed digits represent a full directory number rather than an abbreviated PBX extension.
  • the IP PBX server 40 may analyze the request and thereby determine that it is a call to a PSTN number. (For instance, the fact that the dialed digits are the length or other form of a full directory number rather than the length or form of a simple extension number may indicate that the call is a call to a PSTN number rather than to an IP PBX extension.) In response, the IP PBX server 40 may then set up the call via a PSTN gateway.
  • the IP PBX server 40 may engage in SEP signaling with MGC 74 to set up an RTP call leg between the IP PBX server 40 and another MGW 92 tied to the PSTN 24, and MGC 74 may correspondingly engage in SS7 ISUP signaling (e.g., via STP 26, with SP 28) to set up the call from that MGW 92 via the PSTN 24 to the dialed number (telephone 30).
  • MGC 74 may correspondingly engage in SS7 ISUP signaling (e.g., via STP 26, with SP 28) to set up the call from that MGW 92 via the PSTN 24 to the dialed number (telephone 30).
  • IP PBX sever 40 could set up the call to the outside number via a local telephone company switch.
  • the call could thus proceed between WCD 14 and the called PSTN number, similarly leaving both signaling and bearer paths through the IP PBX server 40.
  • the IP PBX server 40 could thus manage the outside call, to similarly provide IP PBX services, such as call transfer, conference calling, and the like. c. Terminating Outside Calls
  • MSC 22 receives a request to connect an outside call (i.e., a call from a PSTN directory number) to WCD 14, at step 220.
  • MSC 22 may receive an ISUP IAM request from another switching point (e.g., SP 28) in the PSTN 24, seeking to set up a call to the directory number of WCD 14.
  • SP 28 switching point
  • the call could come as a PSTN call from an outside line on the enterprise IP PBX system, but that does not matter.
  • the MSC may then encounter a WIN trigger that points to SCP 32.
  • MSC 22 may send an IS-41 "Analyzedlnfo" message via the signaling network to the SCP, providing the SCP with the calling and called numbers.
  • SCP 32 may then refer to a subscriber profile store to determine that the WCD being called subscribes to IP PBX service.
  • SCP 32 may send an Analyzedlnfo return result to MSC 22, providing the MSC with the routing number of MGC 74, to cause MSC 22 to set up the call to the media gateway system.
  • MSC 22 would then send an ISUP IAM call setup message via STP 26 to MGC 74, providing MGC 74 with the calling and called numbers, and indicating that the call is a WCD-terminated call, at step 224.
  • the MGC may then dip into its correlation data 112 to determine which host IP PBX server serves the terminating WCD 14 (e.g., based on its MDN), at step 225.
  • MGC 74 may thereby get an IP address or SIP address of the applicable IP PBX server, presumably IP PBX server 40, at step 226.
  • MGC 74 may then work on behalf of MGW 72 to set up an RTP call leg between MGW 72 and the selected IP PBX server 40 and a circuit-switched (e.g., PCM) call leg between MSC 22 and MGW 72.
  • MGC 74 could engage in SIP signaling with IP PBX server 40, at step 227, to set up an RTP session between MGW 72 and IP PBX server 40, and MGC 74 could engage in further SS7 signaling with MSC 22, at step 228, to set up a circuit call leg between MSC 22 and MGW 72.
  • the IP PBX server 40 has thus received a signaling message seeking to set up a call to WCD 14. Further, the IP PBX server 40 has a communication bearer path with WCD 14, via the RTP leg, MGW 72, the circuit leg, MSC 22, and cellular air interface 18. Thus, the IP PBX server 40 can apply the enterprise dial plan to determine how to handle the call.
  • Possible options for handling the call might include (i) ringing the WCD 14, (ii) simultaneously or sequentially ringing the WCD 14 and a corresponding desk phone extension at the enterprise, or (iii) sending the call to the WCD's voice mail box at the enterprise IP PBX (or on the enterprise network).
  • General logic, or configuration data for WCD 14, for instance may indicate which of these or other options the IP PBX server 40 should take.
  • IP PBX server 40 might first ring WCD 14 and then, if no one answers, send the call to voice mail or ring another enterprise extension.
  • the IP PBX server 40 may effectively initiate an outbound call (call leg) to the WCD 14, via the media gateway system 70 and the RAN 12. To do so, the IP PBX server 40 could engage in SIP signaling with MGC 74, sending a SIP INVITE that seeks to set up a call to the directory number of WCD 14 (which the IP PBX server 40 had received in the call setup message from the MGC 74), at step 230. At that point, one of two processes (among various others) could be applied.
  • MGC 74 could send an ISUP IAM to the WCD's home MSC, at step 232.
  • Routing logic maintained or accessible by the MGC can ' correlate " the directory number of WCD " 14 " with the " home MSC.
  • the MGC would include in the IAM an indication that this is the second leg of the call, or some other indication that the call has already been routed to the IP PBX system for handling, so as to avoid endless looping.
  • the indication could be a user definable parameter in the IAM message, provided that the home MSC (or SCP, if queried by the home MSC) would be programmed to interpret the parameter value as the indication.
  • the home MSC Upon receipt of the IAM, the home MSC would then encounter a WIN trigger that would cause the home MSC to send an IS-41 "LocationRequest” (LOCREQ) message to the WCD's HLR 34, at step 234. And the HLR 34 then would return to the home MSC a LocationRequest return result (locreq_rr) that provides Advanced Termination Trigger directing the home MSC to send an Analyzedlnfo message to the SCP 32, at step 236.
  • LOCREQ "LocationRequest”
  • the home MSC would thus send an Analyzedlnfo message to the SCP 32, with an indication that this is a second leg of a call (based on the indication it received from MGC 74). And, due to that indication, the SCP 32 would send a "Continue" return result to the home MSC, at step 239.
  • the home MSC would then send another LOCREQ to the HLR to find out where the called cellular WCD is currently located, at step 240.
  • this second LOCREQ would include a trigger value that indicates this is a second LOCREQ and that the WCD location is to be determined, to preclude the HLR 34 from again providing an Advanced Termination Trigger.
  • WCD 14 is in the home MSCs serving system (i.e., if MSC 22 is the home MSC)
  • the HLR would return a locreq_rr providing a "Local Delivery” result, and so the MSC 22 would page/ring the cellular WCD and, if someone answers, connect the call through to the cellular WCD, at step 240.
  • the HLR would send a RouteRequest (ROUTEREQ) to the serving MSC 22 and the MSC 22 would return a RouteRequest return result (routereqjrr) providing ⁇ temporary local directory number (TLDN) to use for setting up the call to the cellular WCD.
  • ROUTEREQ RouteRequest
  • Routereqjrr RouteRequest return result
  • TLDN temporary local directory number
  • the MGC 74 could itself send a LOCREQ to the HLR 34 in an effort to get a TLDN to which the MGC 74 can route the outbound call to WCD 14, at step 242.
  • MGC 74 would receive a locreq_rr that provides the MGC 74 with an Advanced Termination Trigger pointing to the SCP 32.
  • MGC 74 could include in its LOCREQ to HLR 34 a parameter (or lack thereof) indicating that the MGC 74 is not WIN-trigger capable.
  • HLR 34 would not return an Advanced Termination Trigger but would instead proceed to send a ROUTEREQ to the WCD's serving MSC 22 so as to obtain a TLDN for the WCD.
  • HLR 34 would then send the TLDN to MGC 74 in a locreqj ⁇ r, at step 244.
  • MGC 74 could then engage in ISUP signaling with the WCD's serving MSC 22, at step 246, to set up the call to WCD 14 at that TLDN, i.e., via MSC 22.
  • MGC 74 (Another way for MGC 74 to avoid receiving an Advanced Termination Trigger from HLR 34 in response to a LOCREQ is for MGC 74 to indicate in the LOCREQ that it is WTN- trigger capable, but to provide a trigger-type of "location” rather than a trigger-type of "mobile termination.” Given that the trigger-type is "location,” HLR 34 would respond by providing a TLDN rather than providing an Advanced Termination Trigger.)
  • IP PBX server 40 could manage the call, providing IP PBX services, such as call tra ⁇ sfer, ⁇ c ⁇ r ⁇ fere ⁇ ce calling, and the like. ii. Ringing another IP PBX Extension
  • the IP PBX server 40 can simply engage in SIP signaling with the enterprise IP PBX server so as to work to set up the call to the desired extension, in the manner described above for inside call originations.
  • the IP PBX server might do this after failing to connect the call to WCD 14.
  • the IP PBX server 40 might do this at the same time as it seeks to connect the call to WCD 14, perhaps to simultaneously ring WCD 14 and the desk telephone of the WCD's user. In that case, the IP PBX server could connect the call through to whichever one answers the call first. iii. Sending the Call to Voice Mail
  • the IP PBX server 40 could send the call to the WCD's voice mail box at the enterprise IP PBX system. To do so, the IP PBX server 40 could engage in SlP signaling with the voice mail server or with another entity to connect the call to the voice mail server. d. Terminating Inside Calls In this final scenario, as illustrated in Figure 12, assume that another extension of the enterprise IP PBX system dials the extension that the IP PBX system has assigned to WCD 14, at step 250. When that happens, the IP PBX server 40 can determine how to handle the call.
  • Possible handling options include, for instance, (i) ringing the cellular WCD, (ii) simultaneously or sequentially ringing the cellular WCD and a corresponding desk phone extension at the enterprise, or (iii) sending the call to the WCD's voice mail box on the enterprise IP PBX system. These options are discussed in the following subsections. i. Ringing the Cellular WCD
  • the IP PBX server 40 can engage in SIP signaling with MGC 74, and MGC 74 can engage in ISUP signaling with MSC 22, as described above. With additional response signaling, a call path could thus be set up from the IP PBX server 40 to the cellular WCD, via the media gateway system 70 and the RAN 12 serving the cellular WCD, as shown in Figure 9. ii. Ringing another IP PBX Extension
  • the IP PBX server 40 can apply its normal processes.
  • the enterprise IP PBX server might do this after failing to connect the call to WCD 14.
  • the enterprise IP PBX server might do this at the same time as it seeks to connect the call to WCD 14, perhaps to simultaneously ring the cellular WCD and the desk telephone of the cellular WCD's user, hi that case, the enterprise IP PBX server could connect the call through to whichever one answers the call first.
  • the enterprise IP PBX can do so through its normal processes, such as engaging in SIP signaling to connect the call to the enterprise voice mail server.
  • WCD 14 places a call to another extension on the enterprise network, by dialing the extension number.
  • a conventional cellular WCD e.g., cell phone
  • a user would enter the extension number and press "SEND" or another key.
  • An origination message will then pass over an air interface from WCD 14 to MSC 22 in the carrier's RAN ' 12, providing the RAN with (i) the WCD's mobile directory number (MDN) and electronic serial number (ESN) or one or more other identifiers, and (ii) the dialed digits, which, in this case, would be the dialed PBX extension rather than a full directory number.
  • MDN mobile directory number
  • ESN electronic serial number
  • the MSC may then encounter a WIN trigger that points to the SCP.
  • the MSC would send an IS-41 "Origination Request" (ORREQ) message via the signaling network to SCP 32, providing the SCP with the calling and called numbers.
  • SCP 32 may then refer to a subscriber profile store to determine that the WCD originating the call subscribes to cellular-PBX integration service.
  • the SCP will send an Origination Request return result (orreq_rr) to MSC 22, providing the MSC with the routing number of MGC 74, so as to cause MSC 22 to set up the call to the media gateway system.
  • MSC 22 would then send an ISUP IAM call setup message via the signaling network to MGC 74, providing the MGC with the calling and called numbers, and indicating that the call is a WCD-originated call.
  • Existing call signaling protocols define a parameter that can be used to indicate whether a call is a WCD-originated call (a call from a WCD) or a WCD- terminated call (a call to a WCD), for purposes of allowing a call processing entity to determine which party's profile to reference when setting up the call.
  • MGC 74 may then generate and send to CSCF 100 a corresponding SIP INVITE message that specifies the called extension as a telephone number URI in the "To" field, and that includes a header parameter indicating this is a WCD-originated call.
  • the CSCF 100 may then dip into the correlation data 162 of HSS 102 to determine which host IP PBX server serves the originating cellular WCD (e.g., based on its MDN) and may obtain from correlation data 162 a domain name of the serving EP PBX server, such as IP PBX server 40.
  • CSCF 100 may then resporisively query DNS server 132 to resolve the domain name into an L? address of D? PBX server 40, and CSCF 100 may route the INVITE to that IP address.
  • SIP signaling may then proceed between the MGC 74 and D? PBX server 40, via the CSCF 100, to set up a voice/RTP call leg between MGW 72 and IP PBX server 40.
  • ISUP signaling would pass between MGC 74 and MSC 22 to set up a circuit- switched (e.g., PCM) call leg between MSC 22 and the MGW 72.
  • PCM circuit- switched
  • IP PBX server 40 has thus received a signaling message seeking to set up a call from WCD 14 to another IP PBX extension. Further, the D? PBX server 40 has a communication bearer path with WCD 14, via the RTP leg, MGW 72, the circuit leg, MSC 22, and cellular air interface 18. Thus, the D? PBX server 40 can apply the enterprise dial plan and thereby determine that this is a call to one of the enterprise IP PBX extensions. hi response to the determination that this is a call to an enterprise D? PBX extension, the IP PBX server 40 may then set up the call with SIP and RTP to the enterprise telephone station having that extension.
  • the IP PBX server 40 may engage in SlP communication with the called station to set up an RTP call path between the EP PBX server 40 and the called station.
  • the D? PBX server can similarly engage in SEP communication with the called station, via a packet-data link with the enterprise network, and via the enterprise network, to set up an RTP call path between the E? PBX server 40 and the called station.
  • the IP PBX server 40 can conveniently manage the call, providing EP PBX features such as call transfer, conference calling, and the like for WCD 14.
  • the EP PBX server 40 determines for some reason (such as based " on " the " enterprise dialing plan or the WCD's " configuration data) " that the call cannot be connected through to the called party, the EP PBX server 40 (or its associated media server) could play a speech or tone announcement to the caller, via the established bearer path. b. Originating Outside Calls
  • WCD 14 places a call to a PSTN phone number, i.e., to a full PSTN number rather than an EP PBX extension, such as the phone number of telephone 30 for instance.
  • the PSTN number could be a DED number in the enterprise, but that does not matter.
  • This scenario is largely the same as the scenario described above, up until the point where a call path (or associated signaling) is established to the EP PBX system, e.g., to the EP PBX server 40, except that the dialed digits represent a full directory number rather than an abbreviated PBX extension.
  • the EP PBX server 40 may analyze the request and thereby determine that it is a call to a PSTN number. (For instance, the fact that the dialed digits are the length or other form of a full directory number rather than the length or form of a simple extension number may indicate that the call is a call to a PSTN number rather than to an IP PBX extension.)
  • the IP PBX server 40 may then set up the call via a PSTN gateway. For instance, the IP PBX server 40 may engage in SIP signaling via CSCF 100 with MGC 74 to set up an RTP call leg between the D?
  • PBX server 40 and another MGW tied to the PSTN 24, and MGC 74 may correspondingly engage in SS7 ISUP signaling (e.g., via STP 26) to set up the call from that other MGW via the PSTN 24 to the dialed number.
  • SS7 ISUP signaling e.g., via STP 26
  • IP PBX sever 40 could set up the call to the outside number via a local telephone company switch.
  • the call could thus proceed between WCD 14 and the called PSTN number, similarly leaving both signaling and bearer paths through the IP PBX server 40.
  • the D? PBX server 40 could thus manage the outside call, to similarly provide D? PBX services, such as call transfer, conference calling, and the like.
  • MSC 22 receives a request to connect an outside call (i.e., a call from a PSTN directory number) to WCD 14.
  • MSC 22 may receive an ISUP IAM request from another switching point (e.g., SP 28) in the PSTN 24, seeking to set up a call to the directory number of WCD 14.
  • SP 28 switching point
  • the call could come as a PSTN call from an outside line on the enterprise IP PBX system, but that does not matter.
  • the MSC may then encounter a WIN trigger that points to SCP 32.
  • MSC 22 may send an IS-41 "Analyzedlnfo" message via the signaling network to the SCP, providing the SCP with the calling and called numbers.
  • SCP 32 may then refer to a subscriber profile store to determine that the WCD being called subscribes to D? PBX service.
  • SCP 32 may send an Analyzedlnfo return result to MSC 22, providing the MSC with the routing number of MGC 74, to cause MSC 22 to set up the call to the media gateway system.
  • MSC 22 may then send an ISUP IAM call setup message via STP 26 to MGC 74, providing MGC 74 with the calling and called numbers, and indicating that the call is a WCD-terminated call.
  • MGC 74 may then generate and send to CSCF 100 a corresponding SIP INVITE message that specifies the called number (namely, the WCD's number) as a telephone number UPJ in the "To" field, and includes a header parameter indicating that this is a WCD-terminated call.
  • the CSCF 100 may then dip into the correlation data 162 of HSS 102 to determine which host IP PBX server serves the terminating cellular WCD (e.g., based on its MDN) and may obtain from correlation data 162 a domain name of serving IP PBX server, such as IP PBX server 40. CSCF 100 may then responsively query DNS server 132 to resolve the domain name into an IP address of IP PBX server 40, and CSCF 100 may route the INVITE to that IP address.
  • a domain name of serving IP PBX server such as IP PBX server 40.
  • SIP signaling may then proceed between the MGC 74 and IP PBX server 40, via the CSCF 100, to set up a voice/RTP call leg between MGW 72 and IP PBX server 40.
  • ISUP signaling would pass between MGC 74 and MSC 22 to set up a circuit- switched (e.g., PCM) call leg between MSC 22 and the MGW 72.
  • PCM circuit- switched
  • the IP PBX server 40 has thus received a signaling message seeking to set up a call to WCD 14. Further, the IP PBX server 40 has a communication bearer path with WCD 14, via the RTP leg, MGW 72, the circuit leg, MSC 22, and cellular air interface 18. Thus, the IP PBX server 40 can apply the enterprise dial plan to determine how to handle the call.
  • Possible options for handling the call might include (i) ringing the WCD 14, (ii) simultaneously or sequentially ringing the WCD 14 and a corresponding desk phone extension at the enterprise, or (iii) sending the call to the WCD's voice mail box at the enterprise IP PBX (or on the enterprise network).
  • General logic, or configuration data for WCD 14, for instance may indicate which of these or other options the IP PBX server 40 should take.
  • IP PBX server 40 might first ring WCD 14 and then, if no one answers, send the call to voice mail or ring another enterprise extension.
  • the IP PBX server 40 may effectively initiate an outbound call (call leg) to the WCD 14, via the media gateway system 74 and the RAN 12. To do so, the IP PBX server 40 could engage in SIP signaling with MGC 74, via the CSCF 100. For instance, the IP PBX server 40 could send a SIP INVITE that seeks to set up a call to the directory number of WCD 14 (which was indicated in " the call setup message that the IP PBX server " 40 had received from " the MGC 74. At that point, one of two processes (among various others) could be applied.
  • MGC 74 could send an ISUP IAM to the WCD's home MSC. (Routing logic maintained or accessible by the MGC can correlate the directory number of WCD 14 with the home MSC.)
  • the MGC would include in the IAM an indication that this is the second leg of the call, or some other indication that the call has already been routed to the IP PBX system for handling, so as to avoid endless looping.
  • the indication could be a user definable parameter in the IAM message, provided that the home MSC (or SCP, if queried by the home MSC) is programmed to interpret the parameter value as the indication.
  • the home MSC Upon receipt of the IAM, the home MSC would then encounter a WIN trigger that would cause the home MSC to send an IS-41 "LocationRequest” (LOCREQ) message to the WCD's HLR 34. And the HLR 34 then would return to the home MSC a LocationRequest return result (locreq_rr) that provides Advanced Termination Trigger directing the home MSC to send an Analyzedlnfo message to the SCP 32. The home MSC would then send an Analyzedlnfo message to the SCP 32, with an indication that this is a second leg of a call (based on the indication it received from MGC 74). Due to that indication, the SCP 32 would send a "Continue" return result to the home MSC.
  • LOCREQ LocationRequest return result
  • this second LOCREQ would include a trigger value that indicates this is a second LOCREQ and that the WCD location is to be determined, to preclude the HLR 34 from again providing an Advanced Termination Trigger.
  • WCD 14 is in the home MSCs serving system (i.e., if MSC 22 is the home MSC), then the HLR would return a locreqjrr providing a "Local Delivery" result, and so the MSC 22 would page/ring the cellular WCD and, if someone answers, connect the call through to the cellular WCD.
  • the HLR would send a RouteRequest (ROUTEREQ) to the serving MSC 22 and the MSC 22 would return a RouteRequest return result (routereqjr) providing a temporary local directory number (TLDN) to use for setting up the call to the cellular WCD.
  • the HLR would then send a locreq_rr to the home MSC, providing the TLDN, and the home MSC would set up the call to the cellular WCD at that TLDN, i.e., via MSC 22.
  • the MGC 74 could itself send a LOCREQ to the HLR 34 in an effort to get a TLDN to which the MGC 74 can route the outbound call to WCD 14.
  • MGC 74 would receive a locreq_rr that provides the MGC 74 with an Advanced Termination Trigger pointing to the SCP 32.
  • MGC 74 could include in its LOCREQ to HLR 34 a parameter (or lack thereof) indicating that the MGC 74 is not WIN-trigger capable.
  • HLR 34 would not return an Advanced Termination Trigger but would instead proceed to send a ROUTEREQ to the WCD's serving MSC 22 so as to obtain a TLDN for the WCD.
  • HLR 34 would then send the TLDN to MGC 74 in a locreqjT.
  • MGC 74 could then engage in ISUP signaling with the WCD's serving MSC 22, to set up the call to WCD 14 at that TLDN, i.e., via MSC 22.
  • MGC 74 (Another way for MGC 74 to avoid receiving an Advanced Termination Trigger from HLR 34 in response to a LOCREQ is for MGC 74 to indicate in the LOCREQ that it is WIN- trigger capable, but to provide a trigger-type of "location” rather than a trigger-type of "mobile termination.” Given that the trigger-type is "location,” HLR 34 would respond by providing a TLDN rather than providing an Advanced Termination Trigger.)
  • IP PBX server 40 could manage the call, providing IP PBX services, such as call transfer, conference calling, and the like. ii. Ringing another IP PBX Extension
  • the IP PBX server 40 can simply engage in SIP signaling to set up the call to the desired extension, in the manner described above for inside call originations.
  • the IP PBX server 40 might do this after failing to connect the call to WCD 14.
  • the IP PBX server 40 might do this at the same time as it seeks to connect the call to WCD 14, perhaps to simultaneously ring WCD 14 and the desk telephone of the WCD's user. In that case, the IP PBX server could connect the call through to whichever one answers the call first. ii. Sending the Call to Voice Mail
  • the IP PBX server 40 could send the call to the WCD's voice mail box at the enterprise IP PBX system. To do so, the IP PBX server 40 could engage in SIP signaling with the enterprise voice mail server 62 or with another entity to connect the call to the enterprise voice mail server 62. d. Terminating Inside Calls
  • the IP PBX server 40 can determine how to handle the call. Possible handling options include, for instance, (i) ringing the cellular WCD, (ii) simultaneously or sequentially ringing the cellular WCD and a corresponding desk phone extension at " the enterprise, or (iii) sending the call to the WCD's voice mail box at enterprise voice mail server 60. These options are discussed in the following subsections. i. Ringing the Cellular WCD
  • the IP PBX server 40 can engage in SIP signaling with MGC 74 (via the CSCF 100), and MGC 74 can engage in ISUP signaling with MSC 22, as described above. With additional response signaling, a call path could thus be set up from the IP PBX server 40 to the cellular WCD, via the media gateway system 70 and the RAN 12 serving the cellular WCD. ii. Ringing another IP PBX Extension
  • the IP PBX server 40 can apply its normal processes.
  • the enterprise IP PBX server might do this after failing to connect the call to WCD 14.
  • the enterprise IP PBX server might do this at the same time as it seeks to connect the call to WCD 14, perhaps to simultaneously ring the cellular WCD and the desk telephone of the cellular WCD's user. In that case, the enterprise IP PBX server could connect the call through to whichever one answers the call first.
  • the enterprise IP PBX can do so through its normal processes, such as engaging in SIP signaling to connect the call to the enterprise voice mail server.
  • IP PBX servers With the widespread popularity of VoIP communication, many enterprises already have IP PBX servers in place to serve their users on their network.
  • the present invention can be applied to extend those existing IP PBX servers (or later acquired enterprise IP PBX servers) " to serve users of cellular wireless devices as well.
  • One way to do so is to provide a communication path between the enterprise IP PBX server and the cellular carrier's media gateway system, so that the media gateway system can connect calls between the cellular RAN and the IP PBX server, and the IP PBX server can thereby manage the calls in much the same way that the IP PBX server manages calls for the telephone stations on the enterprise LAN.
  • Another way to do so is to provide a centralized host IP PBX server in the carrier's network and to operate the host IP PBX server as a "master" IP PBX server to handle calls for WCD extensions on the enterprise IP PBX system.
  • the master IP PBX server could be the same make and model as the enterprise IP PBX server and would be configured largely (or fully) the same as the enterprise IP PBX server, so that the master IP PBX server can offer the same services as the enterprise IP PBX server.
  • the master IP PBX server can be provisioned with configuration data for each WCD that is set as an extension on the enterprise IP PBX server (the slave IP PBX server), and the configuration data that the enterprise IP PBX server maintains for the WCD can direct the enterprise IP PBX server to turn to the master IP PBX server for call handling when faced with a request to handle a call to or from a WCD.
  • the enterprise IP PBX server itself can be set to fully manage calls involving non-WCD extensions, without the need to interact wit the master IP PBX server.
  • the master IP PBX server can then engage in IP-based call setup signaling with the MGC 74 to establish RTP communication between MGW 72 and the master IP PBX server. Further, the master IP PBX server can engage in both IP-based call setup signaling and RTP bearer communication with the enterprise IP PBX server, and the enterprise IP PBX server can in turn pass signaling and bearer data between the master IP PBX server and the enterprise telephone stations.
  • the enterprise IP PBX server can function as more than a mere conduit. For instance, it can apply some of its own logic to manage WCD calls as well.
  • the master IP PBX server would function as IP PBX server 40 in the description above, though its communications with enterprise telephone stations may pass through the applicable enterprise IP PBX server.
  • An advantage of this arrangement is that it allows the wireless carrier to better manage operation of the IP PBX system, such as to ensure that the IP PBX system and other entities (e.g., HLR, SCP, and media gateway system) are appropriately configured to facilitate serving WCD extensions on enterprise IP PBX system. Further, it can provide a centralized point (the master IP PBX server) with which various enterprise IP PBX servers can be set to communicate, rather than having IP PBX server be set to communicate with more likely many MGCs (distributed in various locations throughout a cellular carrier's network).
  • Figure 13 depicts an example of this master IP PBX server arrangement in the context of Figure 3. As shown in Figure 13, MGC 74 is communicatively linked with a carrier's core packet data network 300.
  • Master IP PBX server 302 is an IP PBX server of "Type A”
  • master IP PBX server 304 is an IP PBX server of "Type B.”
  • Types A and B could be particular makes and models or particular configurations, for instance.
  • Type A could be an Avaya S 8700 IP PBX server for instance
  • Type B could be some other make and model IP PBX server.
  • Network 300 is then coupled with a plurality of enterprise networks 306, 308, 310. Further, sitting as a node on each enterprise network is a respective enterprise IP PBX server as well as a number of representative enterprise IP PBX telephone stations.
  • sitting as nodes on enterprise network 306 are an enterprise IP PBX server 312 and representative enterprise telephone stations 314, 316; sitting as nodes on enterprise network 308 are an enterprise IP PBX server 318 and representative enterprise telephone stations 320, 322; and sitting as nodes on enterprise network 310 are an enterprise IP PBX server 324 and representative enterprise telephone stations 326, 328.
  • IP PBX servers 312 and 324 (on enterprise networks 306, 310) are of Type A
  • IP PBX server 318 on enterprise network 308) is of Type B.
  • Figure 13 also depicts three representative WCDs 330, 332, 334, each of which may be set as extensions on one of the various enterprise IP PBX systems illustrated.
  • the corresponding master IP PBX server (of the same type as the enterprise IP PBX server that serves the WCD) may thus have configuration data for the WCD, largely the same as the enterprise IP PBX server would be configured for the WCD if the master IP PBX server did not exist.
  • WCD 330 may be set as an extension on enterprise IP PBX server 312, and master IP PBX server 302 (of the same type as enterprise IP PBX server 312) may include configuration data for WCD 330;
  • WCD 332 may be set as an extension on enterprise IP PBX server 318, and master IP PBX server 304 (of the same type as enterprise IP PBX server 318) may include configuration data for WCD 332;
  • WCD 334 may be set as an extension on enterprise EP PBX server 324, and master D? PBX server 302 (of the same type as enterprise IP PBX server 324) may include configuration data for WCD 334.
  • MGC 74 may refer to its correlation data 162 and thereby determine that master EP PBX server 302 serves the WCD.
  • the correlation data may associate WCD 330 with enterprise EP PBX server 312 and may then associate EP PBX server 312 with master EP PBX server 302.
  • MGC 74 may thus engage in call setup signaling to set up the call with master EP PBX server 302.
  • Master EP PBX server 302 may then apply the enterprise PBX dialing plan (corresponding to enterprise EP PBX server 312) and the configuration data of WCD 330 to determine how to handle the call.
  • master EP PBX server 302 may then set up the call through enterprise EP PBX server 312 to that extension.
  • MGC 74 may refer to correlation data 162 and thereby determine that master EP PBX server 304 serves the WCD. MGC 74 may thus engage in call setup signaling to set up the call with master EP PBX server 304. Master EP PBX server 304 may then apply the enterprise PBX dialing plan (corresponding to enterprise EP PBX server 318) and the configuration data of WCD 332 to determine how to handle the call. In the event master EP PBX server 304 determines that the call should be connected in turn to an extension on the enterprise network 308, master EP PBX server 304 may then set up the call through enterprise EP PBX server 318 to that extension.
  • the CSCF or an associated policy server could dip into correlation data 162 in HSS 102 to determine which master IP PBX server serves the WCD. The CSCF can then forward call setup signaling between MSGC 74 and that master IP PBX server. This arrangement is illustrated in Figure 14.
  • MGC 72 and CSCF 100 are communicatively linked with the carrier's core packet data network 300. Further sitting as other nodes on network 300 are the two representative master IP PBX servers 302, 304. And network 300 is then coupled with the plurality of enterprise networks 306, 308, 310. Figure 14 also depicts the three representative WCDs 330, 332, 334, each of which may be set as extensions on one of the various enterprise IP PBX systems illustrated.
  • MGC 74 may signal to CSCF 100, and CSCF 100 may dip into HSS 102 and reference correlation data 162 to thereby determine that master IP PBX server 302 serves the WCD.
  • the correlation data may associate WCD 330 with enterprise EP PBX server 312 and may then associate IP PBX server 312 with master IP PBX server 302.
  • CSCF 100 may thus pass the calls setup signaling message to master IP PBX server 302.
  • Master EP PBX server 302 may then apply the enterprise PBX dialing plan (corresponding to enterprise EP PBX server 312) and the configuration data of WCD 330 to determine how to handle the call. Ln the event master EP PBX server 302 determines that the call should be connected in turn to an extension on the enterprise network 306, master EP PBX server 302 may then set up the call through enterprise EP PBX server 312 to that extension.
  • MGC 74 may signal to CSCF 100, and CSCF 100 may dip into HSS 102 and reference correlation data 162 to thereby determine that master EP PBX server 304 serves the WCD. MGC 74 may thus engage in call setup signaling to set up the call with master IP PBX server 304.
  • Master IP PBX server 304 may then apply the enterprise PBX dialing plan (corresponding to enterprise IP PBX server 318) and the configuration data of WCD 332 to determine how to handle the call, hi the event master IP PBX server 304 determines that the call should be connected in turn to an extension on the enterprise network 308, master IP PBX server 304 may then set up the call through enterprise IP PBX server 318 to that extension.
  • an enterprise IP PBX server can be provided entirely by a telecommunications carrier or other entity, such as a wireless carrier Tor instance, with " or without an TP PBX server being situated at the enterprise as well.
  • the IP PBX server can take the form of an IP Centrex server that sits on a carrier's packet network and that is connected through one or more routers or gateways with the enterprise network.
  • IP Centrex server can be arranged to serve multiple different enterprises, with partitioned logic for instance.
  • IP PBX service can provide a significant benefit, in that it allows a user to enjoy IP PBX service features when the user is out of the office and operating a cellular telephone, theoretically anywhere within the coverage provided by the user's wireless carrier.
  • IP PBX extension there may be times when a user who subscribes to such service does not want the service to apply. For instance, during evenings and weekends, the user may want his or her cell phone to function as a personal cell phone, not tied to the user's work IP PBX system, but during weekdays when the user is out of the office, the user may want his or her cell phone to function as an IP PBX extension.
  • logic can be added to enable a WCD user to "check in” and “check out” of the cellular-PBX integration service, such as by allowing the user to activate and deactivate the service or to have a defined schedule that indicates when the service should apply and when it should not apply.
  • Such logic can be implemented in various ways within the example system described above. Two example implementations are described in the following subsections. a. Personal-Enterprise Policy Server
  • HSS 102 will maintain in the WCD's profile an indication of whether the WCD is currently checked-into or checked-out of the system.
  • the indication may be a Boolean flag that a user can set or clear to indicate whether the cellular- PBX integration function should apply or not.
  • the WCD When the flag is set, the WCD would be treated as an extension of the IP PBX system, such as in the manner described above. And when the flag is cleared, the WCD would be treated as a conventional WCD, allowing personal cellular service without cellular-PBX integration.
  • the indication in the WCD's profile may take the form of a schedule that indicates specific times (e.g., times of day, days of week, dates, etc.) when the cellular-PBX integration function should apply and other times when it should not apply.
  • the user will provision the settings in the profile by interacting with a web based provisioning interface provided by a web server tied to the HSS.
  • a web server tied to the HSS.
  • the user may employ a generic web browser on the user's WCD or personal computer to browse to an address of the web server and, after being authenticated, may receive a report of the current profile settings and make changes to the profile settings.
  • the web server would then preferably populate or update the WCD's profile in HSS 102 accordingly (e.g., by writing directly to the profile, or by sending a signal to another entity to update the profile).
  • MSC 22 When a call is placed to the directory number of WCD 14, as described above, MSC 22 would receive a request to terminate the call and (as instructed by SCP 32, for instance) would responsively set up the call to media gateway system 74. In particular, MSC 22 would engage in ISUP signaling with MGC 74. In the process, MGC 74 would then send to CSCF 100 a SIP INVITE message that specifies in the "To" field the called telephone number, which is the directory number of the WCD.
  • the CSCF 100 will then responsively dip into HSS 102 and thereby determine that the called number is assigned to an account that subscribes to cellular-PBX integration service.
  • the CSCF 100 will pro grammatically route the INVITE or a corresponding message to PE policy server 136 to enable a determination of whether the WCD is currently checked-into or checked-out of the service.
  • the HSS profile for the WCD may specify a domain name for the PE policy server 136, such as "pe-policy.com", or CSCF 100 may be programmed with an indication of that domain name.
  • the CSCF 100 may then append that domain name to the end of the telephone number URI in the "To" field of the SIP INVITE, so as to create a full SIP address in the form "+9876543210@pe-policy.com" To route that SIP INVITE, the CSCF 100 may then dip into the DNS server 132 to determine an IP address corresponding to that domain name and may then transmit the INVITE to that IP address, i.e., to the PE policy server 136.
  • the PE policy server 136 Upon receipt, the PE policy server 136 will then pro grammatically analyze the called number and will itself dip into HSS 102 to determine whether the called WCD is currently checked-into of checked-out of the cellular-PBX integration function.
  • the PE policy server 136 If the PE policy server 136 thereby determines that the called WCD is not checked into the system (i.e., is currently checked out of the system), the PE policy server 136 will then signal back to the CSCF 100 to cause the CSCF 100 to set up the call back to the media gateway system 70 for connection back to MSC 22 and to the WCD 14.
  • the PE policy server 136 can insert in the SIP INVITE a predetermined code that will direct the CSCF 100 to set up the call back to the media gateway system 70, and may then send the INVITE back to the CSCF 100.
  • the predetermined code could be a sequence of five "9"s prepended to the called number in the "To" field, but it could take other forms and be set forth in some other manner in the INVITE, provided that the CSCF is programmed to detect the code and respond accordingly.
  • the PE policy server or the CSCF can strip the PE policy server domain from the "To" field of the INVITE message to direct call setup to the directory number of the WCD.
  • the PE policy server 136 can change the URI in the "To" field to include a domain name of the MGC 74.
  • the CSCF 100 receives the INVITE and detects the predetermined code or domain, the CSCF will responsively send the INVITE or a corresponding message to MGC 74, seeking to set up the call to the directory number of WCD 14. The MGC 74 will then responsively engage in ISUP signaling with MSC 22 to set up the call to the WCD.
  • the PE policy server 136 determines that the called WCD is currently checked into the cellular-PBX integration service, the PE policy server 136 will then signal back to the CSCF 100 to cause the CSCF 100 to set up the call to IP PBX server 40.
  • the PE policy server 136 may determine from the WCD's HSS profile a domain name of the IP PBX server that serves the WCD, such as "ippbx40.com", and the PE policy server 136 may substitute that domain name in the "To" field of the SIP INVITE. The PE policy server 136 may then send that INVITE to the CSCF 100.
  • the CSCF 100 may then dip into DNS server 132 to determine an IP address corresponding to that domain name and may then transmit the INVITE to that IP address, i.e., to IP PBX server 40. Processing can then continue as described above. ii. Terminating Inside Calls hi accordance with the exemplary embodiment, when a call is placed to the WCD's assigned PBX extension, the IP PBX server 40 will programmatically send a SIP INVITE to the CSCF 100, to facilitate a determination of whether the WCD is currently checked-in or checked-out and to facilitate appropriate handling of the call.
  • the IP PBX server 40 will include as the called number in the "To" field of the SIP INVITE the 10-digit directory number of the WCD. Further, the IP PBX server 40 may include in the INVITE a predetermined code that will function as a programmatic directive to cause the CSCF to signal to PE policy server 136. For instance, the IP PBX server 40 can prepend five "8"s to the directory number, and the CSCF can be programmed to interpret the five "8"s as an indication that the CSCF should responsively signal to the PE policy server 136.
  • the CSCF 100 Upon receipt of the INVITE from the IP PBX server 40, the CSCF 100 will thus send the INVITE or a corresponding message to the PE policy server 136, preferably first stripping the prepended digits from the directory number. The PE policy server 136 will then analyze the called number and will dip into HSS 102 to determine if the called WCD is currently checked-into or checked-out of the cellular-PBX integration function.
  • the PE policy server 136 will then signal back to the CSCF 100 to cause the CSCF 100 to set up the call back to the IP PBX server 40.
  • the PE policy server 136 can include in the message a predefined code that the CSCF 100 would interpret as an instruction to not pass the call to the WCD.
  • the CSCF 100 which has a pending SIP INVITE from the IP PBX server 40, will preferably send a SIP response message to the IP PBX server 40, indicating that the call cannot be completed to the WCD.
  • the CSCF can send a SIP REDIRECT message, redirecting the call to the WCD's voice mail box, or the CSCF can send some other SIP "unavailable" message.
  • the IP PBX server 40 can then operate as it normally does when a call cannot be completed.
  • the PE policy server 136 determines that the WCD is currently checked into the system, then the PE policy server 136 will send a signal to the CSCF 100 that will cause the CSCF 100 to route the call to the media gateway system for connection in turn to MSC 22 and to the WCD 14.
  • the PE policy server 136 remove the prepended "8"s from the called number and replace them with a sequence of five "9”s prepended to the called number, and then send the SIP INVITE to the CSCF 100.
  • the CSCF 100 receives an INVITE that has the five "9”s prepended to the called number (or contains some other predetermined code)
  • the CSCF 100 will responsively send the INVITE to MGC 74 (preferably after first stripping the prepended "9"s), to set up the call to the called number.
  • MGC 74 Upon receipt of the INVITE, MGC 74 would then engage in ISUP signaling with MSC 22 to set up the call to the WCD. iii. Originating Calls from the WCD
  • WCD 14 initiates a call to a set of dialed digits
  • the process described above would apply to set up the call to media gateway system 70 and provide a SIP INVITE to CSCF 100.
  • MSC 22 may set up the call to media gateway system 70, and MGC 74 may then send a SIP INVITE to CSCF 100.
  • the INVITE would preferably include a predetermined code or other indication that the calling number, in the "From" field, is a WCD.
  • the CSCF 100 will then responsively dip into HSS 102 and thereby determine that the calling number is assigned to an account that subscribes to cellular-PBX integration service.
  • the CSCF 100 will programmatically route the INVITE or a corresponding message to PE policy server 136 to enable a determination of whether the WCD is currently checked-into or checked-out of the service.
  • the PE policy server 136 determines that the calling WCD is not checked into the system, the PE policy server 136 will responsively send a signal to the CSCF 100 to cause the CSCF 100 to set up the call back to the media gateway system 74.
  • the PE policy server 136 can do this in the ways described above for instance, such as by changing the URI of the called party to include an MGC domain name, or by including in the INVITE a predetermined code that will direct the CSCF 100 to route the INVITE to the MGC 74. hi either case, the MGC 74 will then set up the call back through MSC 22, to allow MSC 22 to handle the call conventionally, such as by attempting to connect the call through the PSTN to the called party.
  • the PE policy server 136 determines that the calling WCD is checked into the system, then the PE policy server 136 will send a signal to the CSCF 100 to cause the CSCF 100 to route the call to the IP PBX server 40 for handling.
  • the PE policy server 136 can apply an IP PBX server domain name to the called URI in the "To" field, and the CSCF 100 can then dip into the DNS server 132 and route the INVITE to the corresponding IP address of IP PBX server 40. Processing can then continue as described above.
  • SCP Policy Server
  • SCP 32 (rather than, or in addition to, HSS 102) will maintain in the WCD's profile an indication of whether WCD is currently checked- into or checked-out of the system, " and/or a schedule that indicates times when the WCD is checked-in and times when the WCD is checked-out.
  • a user will preferably provision this profile through a web-based interface.
  • feature-codes e.g., # or * codes
  • HSS 102 could maintain the profile record for the WCD as in the above embodiment, and SCP 32 could be programmed (or directed by WCD profile parameters) to dip into HSS 102 to determine whether the WCD is currently checked-in or checked-out.
  • the SCP 32 could be provided with a packet-network connection, through which it can communicate with the HSS, such as by sending a remote procedure call or the like.
  • the SCP 32 and HSS 102 could be integrated together as a common network entity.
  • Terminating Calls to the WCD When MSC 22 receives a request to terminate a call to the WCD's directory number, the MSC will encounter an intelligent network trigger and will responsively signal to the SCP 32, sending an Analyzedlnfo message indicative of a call termination attempt. By reference to the WCD's profile record, the SCP will then determine whether the called WCD , is currently checked-into or checked-out of the cellular-PBX integration service.
  • the SCP determines that the WCD is not checked into the system, the SCP will signal back to the MSC, directing the MSC to conventionally handle the call termination, and the MSC will then do so.
  • the SCP determines that the WCD is checked into the system, then the SCP will signal back to the MSC, directing the MSC to set up the call to the media gateway system. The MSC will then do so, and processing will continue as described above for instance.
  • the MSC When the MSC receives a request from the WCD to originate a call, the MSC will similarly encounter a trigger and responsively signal to the SCP, sending an Origination Request indicative of a call origination attempt. The SCP will then determine whether the calling WCD is currently checked-into or checked-out of the system.
  • the SCP determines that the WCD is not checked into the system, the SCP will signal back to the MSC, directing the MSC to conventionally handle the call origination, and the MSC will then do so.
  • the SCP determines that the WCD is checked into the system, the SCP will signal back to the MSC, directing the MSC to set up the call to the media gateway system. The MSC will then do so, and processing will continue as described above for instance.
  • the identity of the party with whom the WCD is engaging in a call can be used as a basis to determine whether to apply cellular-PBX integration or not.
  • the WCD's profile e.g., at HSS 102 and/or SCP 32
  • the entity may then refer to the WCD's profile to determine whether the party with whom the call would be connected is one for which cellular-PBX integration should be applied. For instance, for an outgoing call from WCD 14, the decision could " be ' Tiased on the dialed digits, while, for an incoming call to WCD 14, the decision could be based on the telephone number or extension of the calling party.
  • a WCD user may specify in his or her profile that calls to or from the user's spouse should be not be treated as cellular-PBX integration calls, so that the a call between the WCD's directory number and the spouses telephone number would not be routed through the IP PBX server 40.
  • a WCD user may specify in his or her profile that calls to or from the user's work colleagues or boss should be treated as cellular- PBX integration calls, so that a call between the WCD and the boss's telephone number would be routed through the IP PBX server 40.
  • Other examples are possible as well.
  • the act of determining, based at least in part on the other party's identity, whether or not to apply cellular-PBX integration can be considered another manner of determining whether or not the WCD is "checked-in” or "checked-out" on a per-call basis. If the determination is to not apply cellular-PBX integration due in part to the identity of the other party, then the WCD can be considered “checked-out.” Whereas, if the determination is to apply cellular-PBX integration due in part to the identity of the other party, then the WCD
  • Figures 15 and 16 are flow charts depicting example sets of functions that can be carried out to provide selective check-in/check-out functionality.
  • a WCD's profile record is provisioned to indicate whether the WCD is checked-into or checked-out of a cellular-PBX integration service.
  • a RAN serving the WCD receives a call request for the WCD.
  • a first leg of the call is requested to be set up between the RAN and a media gateway system, and call setup signaling is sent from the media gateway system to a CSCF.
  • a WCD's profile record is provisioned to indicate whether the WCD is checked-into or checked-out of a cellular-PBX integration service.
  • a RAN serving the WCD receives a call request for the WCD.
  • the RAN signals to an SCP for call processing guidance.
  • the SCP determines whether the WCD is currently checked-into or checked-out of the cellular-PBX integration service, such as by reference to the profile record. If the determination is that the WCD is checked-in, then, at step 420, the SCP directs the RAN to set up the call to a media gateway system for connection in turn to an IP PBX server that serves the WCD. On the other hand, if the determination is that the WCD is checked-out, then, at step 422, the SCP directs the RAN to handle the call as normal. 8. Selective Voice-Mail Routing
  • voice mail service may be provided by both a cellular wireless carrier and an enterprise IP PBX system.
  • a voice mail server 106 provided by a cellular carrier may reside on packet- switched network 130, and the carrier's media gateway system 70 may be arranged to connect unanswered, blocked or busy calls to that voice mail server 106.
  • another voice mail server 62 may be provided on an enterprise network, and IP PBX server 40 may be arranged to connect unanswered, blocked or busy calls to that voice mail sever 62!
  • VM policy server 140 is to introduce voice mail (VM) policy server 140 into the cellular-PBX integration system, as shown in Figure 5, and to configure the system to invoke the VM policy server 140 when a need arises to select a destination voice mail box.
  • CSCF 100 may send a SIP signal to the VM policy server 140, and the VM policy server 140 may determine whether to connect the call to the WCD's cellular voice mail box or to the WCD's enterprise voice mail box.
  • the VM policy server 140 may then signal back to the CSCF 100 in a manner that directs CSCF 100 to route the call to the selected voice mail box.
  • VM policy server 140 can decide in various ways which voice mail server should handle a given call. In one embodiment, for instance, VM policy server 140 can dip into HSS 102 and determine based on the WCD's profile which voice mail server to use. In this regard, the WCD's profile could specify voice mail systems to use depending on the calling party, the time of day, or other factors. Alternatively, the decision of which voice mail system to use can be keyed to whether the WCD is currently checked-into or checked-out of the system, such as by " selecting the enterprise voice mail system if the WCD is checked-in and selecting the cellular voice mail system if the WCD is checked-out.
  • the VM policy server 140 will preferably include, embody, or be interconnected with an integrated voice response unit (IVRU), such as a voice-XML (VXML) based platform, as depicted in Figure 5 for instance.
  • IVRU integrated voice response unit
  • the process of invoking the VM policy server 140 can then involve connecting the calling party to the rVRU. Once connected, the IVRU may then prompt the calling party to select a voice mail system for handling the call. In response to the caller's selection, the IVRU may then direct the CSCF 100 to redirect the call to the selected voice mail server.
  • VXML voice-XML
  • this arrangement gives the caller more direct control over the voice mail routing decision for a given called WCD.
  • a caller may opt to have a call connected to the WCD's cellular voice mail box, and in other instances, a caller may opt to have a call to the same number connected instead to the WCD's enterprise voice mail box.
  • the WCD may dial its own directory number, so as to force a connection with voice mail.
  • a feature code or other mechanism could be defined to trigger a connection with voice mail.
  • any call request to connect with voice mail can be considered a "voice mail call request.”
  • MSC 22 will engage in ISUP signaling with MGC 74 to set up the call to media gateway system 70 in the manner described above for instance.
  • MGC 74 will then send a SIP INVITE for the call to CSCF 100, with the INVITE specifying the same number in both the calling ("From") and called ("To”) fields.
  • the CSCF 100 Upon receipt of the INVITE, the CSCF 100 will then detect that the calling and called numbers are the same and will therefore conclude that the WCD is attempting to call itself. In response, the CSCF 100 will dip into the WCD's profile in HSS 102 to ascertain (i) the domain or IP address of the IVRU (VM policy server) 140, and (ii) descriptors and domain names or IP addresses of the voice mail servers that are available to handle the call, i.e., the voice mail servers that host voice mail boxes for the WCD.
  • the voice mail servers that host voice mail boxes for the WCD.
  • the CSCF 100 will then forward the SIP INVITE or send a corresponding message to the rVRU (first dipping into DNS server 132 if necessary), and would provide within the SIP INVITE a directive for the IVRU to prompt the caller to select a voice mail system.
  • the CSCF 100 may include in one or more SIP header parameters in the INVITE a VXML script will cause the IVRU to play out a prompt such as "Press 1 for personal (cellular) voice mail, or press 2 for corporate (enterprise) voice mail," and that links each choice to a respective URL tying the WCD's number with a given voice mail server.
  • choice 1 could be linked to the URL "+9876543210@cellular-vms.com” (for voice mail server 106) and choice 2 could be linked to the URL "+987654321 O@enterprise-vms.com” (for voice mail server 62).
  • the IVRU may engage in continued SIP signaling (e.g., 200 OK / ACK) with the MGC 74, via the CSCF 100, so that a bearer path can be set up between the MGW 72 and the IVRU and thus ultimately between the calling WCD and the IVRU.
  • SIP signaling e.g., 200 OK / ACK
  • the IVRU will then play out the specified prompt to the calling WCD, and the rVRU will receive from the WCD a spoken or DTMF selection of the desired voice mail server.
  • the IVRU will then preferably send to the CSCF 100 a SIP REDIRECT message that may pass in turn to the MGC 74 (or stop wherever the SIP signaling initiated).
  • the SIP REDIRECT will include as a redirect-URL the URL that was associated with the selected voice mail server, such as "+9876543210@cellular-vms.com” or "+9876543210@enterprise-vms.com”.
  • the MGC 74 (or other initiating SIP endpoint) would then send a SIP INVITE to the newly designated URL and engage in further SIP signaling to establish a bearer path between the caller and the selected voice mail server. Further, the telephone number in the URL would indicate to the voice mail server that the call is to be connected to the WCD's voice mail box.
  • the selected voice mail server is the cellular voice mail server 86, then the SIP signaling would thus pass through network 130 between MGC 74 and voice mail server 106.
  • the selected voice mail server is the enterprise voice mail server 62, then the SIP signaling would pass through network 130 between MGC 74 and voice mail server 62.
  • enterprise voice mail server 62 will be tied directly to network 132 to facilitate this signaling and to enable a resulting bearer path to extend from MGW 72 to the enterprise voice mail server 62 without involving the IP PBX server 40.
  • the signaling and bearer path to connect with enterprise voice mail server 62 could extend through IP PBX server 40, but precautions would be put in place to avoid an endless loop condition.
  • CSCF 100 When a third party places a call to the WCD (either to the WCD's directory number or its IP PBX extension) and the call is unanswered, blocked, or busy, CSCF 100 will preferably receive a SIP message, such as a SIP BUSY, that indicates the call cannot be connected to the WCD.
  • SIP message such as a SIP BUSY
  • the CSCF 100 may dip into HSS 102, and send a signal to the IVRU of VM policy server 140, the IVRU would prompt the caller to select a voice mail server to handle the call, and the IVRU would then send a SIP REDIRECT or otherwise direct the call to be connected to the WCD's voice mail box on the selected voice mail server.
  • FIG 17 is a flow chart depicting an example set of functions that can be carried out to provide dynamic voice mail routing.
  • a RAN receives a voice mail call request for a subscriber (such as a call from the subscriber to the subscriber's voice mail, or a call from a third party that is not connected to the subscriber).
  • a first leg of the call is set up from the RAN to a media gateway system.
  • a second leg of the call is set up from the media gateway system to an automated voice response system.
  • the automated voice response system prompts the caller to select a voice mail system from among a plurality of voice mail systems.
  • the automated voice response system receives a selection of a voice mail system from the caller.
  • the second leg is then connected instead from the media gateway system to the selected voice mail system for handling.
  • the call can remain connected through the automated voice response system, to the selected voice mail system.
  • the automated voice response system can itself function as the selected voice mail system, in which case the second leg can remain connected to the automated voice response system but can then be handled as a call to voice mail would be handled.
  • SCP 32 can provide for selective voice mail routing.
  • MSC 22 may encounter a WIN trigger that causes MSC 22 to signal up to SCP 32.
  • SCP 32 may then responsively consult the WCD's profile record arid determine which of multiple voice mail systems should receive the call.
  • the MSC 22 would have trunk connections (not shown) or other links with the various voice mail systems, such as servers 62 and 106, so MSC 22 can set up the call to a selected voice mail system via such a trunk.
  • MSC 22 could set up the call to a selected voice mail system via media gateway system 70.
  • the SCP may direct the MSC to set up the call to a given voice mail system if the WCD is currently checked-into the cellular- PBX integration service, and the SCP may direct the MSC to set up the call to a different voice mail sever if the WCD is currently checked-out of the cellular-PBX integration service.
  • the SCP could apply still other logical conditions as a basis to select which voice mail system should receive the call.
  • the SCP could first direct the MSC 22 to set up the call to a voice response platform that can operate in the manner described above to allow the caller to select a voice mail system, and the voice response platform may signal to the SCP to instruct the SCP which voice mail system should receive the call. The SCP may then direct the MSC 22 to set up the call to the selected voice mail system. Other arrangements are possible as well. 9. Temporary Bypass or Application of Cellular-PBX Integration
  • the selective check-in / check-out logic described above will enable a user to effectively activate or deactivate the cellular-PBX integration service.
  • a WCD user may want to temporarily bypass or apply the cellular- PBX integration feature, without turning on or off the service. For instance, when the WCD's profile indicates that the WCD is checked-in, the user of the WCD may want to place a personal call that does not get routed through the IP PBX system. Similarly, when the WCD's profile indicates that the WCD is checked-out, the user may want to place a call through the IP PBX system.
  • logic can be added to enable a WCD user to bypass or apply cellular-PBX integration on a per-call basis. That is, logic may be provided to allow a user to check-in or check-out a WCD on a per-call basis, possibly overriding the normal check-in/check-out status indicated by the WCD's profile. Two embodiments of this process are described in the following subsections, again with understanding that numerous variations are possible.
  • the user when a user dials a call on WCD, the user can include with the dialed digits a predefined feature code that will toggle the cellular-PBX integration function for that call only. If the WCD is currently checked-in, the feature code will cause cellular-PBX integration to not apply for the call, and if the WCD is currently checked-out, the feature code will cause the cellular-PBX integration function to apply for the call.
  • separate "bypass" and "apply” feature codes could be defined respectively for not applying cellular-PBX integration and for applying cellular-PBX integration.
  • the MSC 22 can signal to SCP 32, and SCP 32 can respond to the feature code by either directing the MSC 22 to connect the call to media gateway system 70 or not. For instance, if the feature code is a temporary bypass directive (or if SCP profile data indicates that the WCD is currently checked-in and the feature code is a toggle code), then the SCP would preferably direct the MSC 22 to handle the call as a normal cellular call, without causing the call to be routed to the media gateway system 70 and CSCF 100.
  • the feature code is a temporary bypass directive (or if SCP profile data indicates that the WCD is currently checked-in and the feature code is a toggle code)
  • the SCP would preferably direct the MSC 22 to handle the call as a normal cellular call, without causing the call to be routed to the media gateway system 70 and CSCF 100.
  • the SCP would preferably direct the MSC 22 to set up the call to the media gateway system, and cellular-PBX processing would occur as described above.
  • the dialed feature code can accompany the dialed digits that are provided in a SIP signaling message to CSCF 100, and CSCF 100 or an applicable policy server (such as PE policy server 136 for instance) can be invoked based on the feature code to determine whether to apply cellular-PBX integration or not.
  • CSCF 100 would either route the call to IP PBX server 40 (if cellular-PBX integration is to be applied for the call) or back to the media gateway system 70 (if cellular-PBX integration is not to be applied for the call).
  • the IVRU function described above with respect to the VM policy server 140 can be varied in a way that will let the WCD user select whether to bypass or use the cellular-PBX integration service for the current call.
  • a separate IVRU or other automated voice response system can be provided to carry out the function in a similar manner, with or without also relating to voice mail server selection.
  • the HSS profile for the WCD will specify that when the WCD calls its own number, the WCD user may be prompted not only to select a voice mail server to receive the call, but also with an option to dial digits that " will be out- dialed without passing through the EP PBX server 40, i.e., to bypass cellular-PBX integration.
  • CSCF 100 when CSCF 100 receives a SIP INVITE seeking to set up a call from WCD 14 to WCD 14, the CSCF would dip into HSS 102 as described above and would receive information that causes the CSCF to set up the call to the IVRU and to direct the IVRU to prompt the caller for a selection.
  • the prompt may, for instance, state "Press 1 for personal voice mail, press 2 for corporate voice mail, or press .3 to dial digits and place a call without cellular-PBX integration.”
  • the IVRU may then prompt the user to dial digits in order to place a phone call.
  • the rVRU may then set up and bridge a call to the dialed number, or the IVRU may send a SEP REDIRECT or similar message as above seeking to set up a call to the dialed number, without involving EP PBX server 40.
  • An analogous process could be carried out to enable a WCD user to selectively apply cellular-PBX integration, rather than selectively bypassing cellular-PBX integration.
  • FIG 18 is a flow chart depicting an example set of functions that can be carried out to provide for temporary bypass or application of cellular-PBX integration service.
  • a RAN serving the WCD receives a call request for the WCD, the call request including a directive of whether or not to apply cellular-PBX integration service for the call.
  • a first leg of the call is requested to be set up between the RAN and a media gateway system, and call setup signaling is sent from the media gateway system to a CSCF.
  • the directive is used as a basis to determine whether the WCD is currently checked-into or checked-out of the cellular-PBX integration service. For instance, if the directive is to apply cellular-PBX integration, then the determination may be that the WCD is considered checked-into the cellular-PBX integration service (e.g., even if just for the present call), and if the directive is to not apply cellular-PBX integration, then the determination may be that the WCD is considered checked-out of the cellular-PBX integration service (e.g., even if just for the present call).
  • the call setup signaling is passed from the CSCF to an IP PBX server that serves the WCD, to request set up of a second leg of the call from the media gateway system to the IP PBX server.
  • signaling is passed back from the CSCF to the media gateway system to request setup of the call back from the media gateway system to the RAN.
  • IP PBX IP Multimedia Subsystem
  • integrating cellular telephone service with IP PBX service will advantageously enable a WCD user to enjoy numerous IP PBX features, such as the ability to place and receive PBX extension-dialed calls, and the ability to place outside calls through the EP PBX server (e.g., using the enterprise's PSTN service provider), for instance.
  • IP PBX features such as the ability to place and receive PBX extension-dialed calls, and the ability to place outside calls through the EP PBX server (e.g., using the enterprise's PSTN service provider), for instance.
  • cellular-PBX integration it may be desirable to limit the locations where cellular-PBX integration can apply. For example, it may be desirable to limit cellular-PBX integration to apply only when the WCD is in one or more specified locations or only when the WCD is not in one or more specified locations.
  • an enterprise EP PBX administrator may wish to prevent a WCD from using of cellular-PBX integration service when the WCD is in located anywhere other than a designated "home" area.
  • the WCD's profile at the SCP 32 will indicate one or more location-based restrictions for application of cellular-PBX integration service.
  • the location-based restrictions may define one or more location "zones" in which cellular-PBX integration service is to apply or is not to apply.
  • Each such zone can be defined in various ways, examples of which include (i) geographic polygons, with nodes defined as latitude/longitude coordinates, (ii) cellular coverage areas, such as sectors, cells, or MSC serving areas, for instance, or (iii) political zones, such as streets, counties, cities or states, for instance. Other examples are possible as well.
  • MSC 22 when MSC 22 is faced with a request to connect a call to or from WCD 14, MSC 22 will signal to SCP 32 in a conventional manner. SCP 32 will then query the WCD's service profile record and thereby determine that the WCD subscribes to cellular- PBX integration service and that the service is location-restricted, hi response, SCP 32 will determine the current location of the WCD.
  • the SCP can determine the current location of the WCD in various ways, depending for instance on the zone definitions that define the restriction at issue.
  • the SCP can determine the WCD's current MSC serving area based simply on which MSC signaled to the SCP, as indicated by a point-code or MSC-ID carried in the signaling message for instance.
  • the SCP could send a position- determination request via STP 26 to MPC 39, seeking a granular reading of the WCD's current location.
  • the MPC may then determine the WCD's location arid report the location in a response message to the SCP.
  • the SCP, MPC, or some other entity can further apply mapping data to convert a determined location into some other form, such as by converting geographic coordinates to a street address, city, or the like.
  • the SCP may then programmatically determine, based on the location and the location-restrictions defined by the WCD's profile (or generally applicable location-restriction logic), whether the call should be handled as a cellular-PBX integration call or not. For instance, if the WCD is located in an area where the profile logic indicates cellular-PBX integration service should apply, then the SCP would determine that cellular-PBX integration service should apply for the current call. Whereas, if the WCD is located in an area where the profile logic indicates cellular-PBX integration service should not apply, then the SCP would determine that cellular-PBX integration should not apply for the current call.
  • the SCP may instruct the MSC to set up the call to media gateway system 70, and processing would continue as described above.
  • the SCP may instruct the MSC to handle the call as a conventional cellular call.
  • the decision of whether to apply cellular-PBX integration can be made by the CSCF or by an associated location policy server 138.
  • the WCD's profile at HSS 102 will indicate one or more location-based restrictions for application of cellular-PBX integration service, defined in the manner described above for instance.
  • CSCF 100 When CSCF 100 receives a SIP INVITE indicative of a call being placed to or from WCD in any of the scenarios described above for instance, the CSCF 100 will dip into HSS 102 and ' determine from the " WCD's profile that a location-based restriction exists on application of cellular-PBX integration service. Further, the CSCF may thereby ascertain a domain name of location policy server 138, such as "location-policy.com". The CSCF may then responsively send the INVITE or a corresponding message to location policy server 138.
  • the location policy server 138 may then itself dip into HSS 102 and thereby determine the applicable location-restrictions, such as the one or more zones in which cellular-PBX integration service is to apply or is not to apply. Further, the location policy server 138 may determine the current location of the WCD, by querying MPC 39 for instance.
  • the location policy server may thus programmatically determine, based on the WCD's location and the location-restrictions defined by the WCD's profile (or generally applicable location-restriction logic), whether the call should be handled as a cellular-PBX integration call or not. For instance, if the WCD is located in an area where the profile logic indicates cellular-PBX integration service should apply, then the location policy server 138 would determine that cellular-PBX integration service should apply for the current call. Whereas, if the WCD is located in an area where the profile logic indicates cellular-PBS integration service should not apply, then the location policy server 138 would determine that cellular- PBX integration should not apply for the current call.
  • the location policy server 138 may signal back to the CSCF 100 to cause the CSCF to apply cellular-PBX integration.
  • the location policy server 138 may signal back to the CSCF 100 to cause the CSCF to not apply cellular-PBX integration.
  • the function of applying or not applying cellular PBX integration can be carried out in the same manner as described above with respect to the check-in / check-out policy logic.
  • Figure 19 is a flow chart depicting an example set of functions that can be carried out to provide for location-based restriction on application of cellular-PBX integration service.
  • a RAN serving the WCD receives a call request for the WCD.
  • a first leg of the call is requested to be set up between the RAN and a media gateway system, and call setup signaling is sent from the media gateway system to a CSCF.
  • an enterprise might also want to restrict application of cellular-PBX integration based on the extent of use. For instance, an enterprise administrator may want to preclude a WCD user from using the cellular-PBX integration function more than a designated number of minutes per month. By the same token, a cellular carrier or other entity might want to restrict a WCD's use of cellular-PBX integration based on the extent of use.
  • a WCD may be allotted a designated quantity of cellular-PBX integration service, possibly with a time restriction, such as per month or other billing period.
  • the balance of minutes of use for a given WCD may then be decremented as the WCD uses the cellular-PBX integration service. And once the balance is exhausted, the WCD would be precluded from using further cellular-PBX integration service (e.g., during the applicable period).
  • the WCD's profile will be provisioned initially (or periodically) with an account balance specifying an allowed quantity of use, such as a number of minutes of call time for instance.
  • an entity that sits within the call signaling path between the cellular carrier's RAN 12 and the IP PBX server 40 will then decrement that account balance for the WCD as the WCD engages in cellular-PBX integration calls.
  • the WCD's profile in HSS 102 can be provisioned with a value that indicates a number of allowed minutes of use of cellular-PBX integration service.
  • an account-balance policy server 142 can be provided on network 90.
  • CSCF 100 may perform some or all of the functions described above to determine whether the cellular-PBX integration service should be provided, such as whether the WCD is currently checked-into or checked-out of the cellular-PBX integration
  • the CSCF 100 when CSCF 100 dips into the WCD's profile at HSS 102, the CSCF 100 will determine that the WCD is subject to an account-balance restriction, and the CSCF 100 may receive a domain name of account balance policy server 100, such as "account-balance- policy.com" In response, the CSCF 100 will thus preferably forward the SP INVITE to the account-balance policy server 142.
  • the account-balance policy server 142 may itself then dip into the WCD's HSS profile, to determine the current account balance for the WCD, such as how many minutes of use the WCD has left. (Alternatively, the CSCF 100 could provide this information in a SIP header parameter to the account balance policy server when forwarding the SIP INVITE to the server.) Based on the remaining balance, the account- balance policy server 100 may then determine whether the WCD has a sufficient balance to proceed with the cellular-PBX integration call that is being set up. For this purpose, a balance can be considered sufficient if it is non-zero or if it surpasses some other designated threshold level (such as 5 minutes for instance.)
  • the account-balance policy server 142 determines that the WCD does not have a sufficient remaining balance, the account-balance policy server 142 will send a response message back to CSCF 100 directing CSCF 100 to not apply cellular-PBX integration. Processing would then occur as described above (as when the PE policy server 136 determines that the WCD is not currently checked-into the system). On the other hand, if the account-balance policy server 142 determines that the WCD does have a sufficient balance, the account-balance policy server 142 would then forward the received SEP INVITE back to the CSCF 100 for transmission in turn to the destination SD? entity. For example, if the SB?
  • INVITE had originated at MGC 74 and passed to CSCF 100 and then to account-balance policy server 142, the INVITE could then pass back to CSCF 100 and, from there, along to IP PBX server 40 for IP PBX handling.
  • the SlP INVITE had originated at IP PBX server 40 and passed to CSCF 100 and then to account-balance policy server 142, the INVITE could then pass back to CSCF 100 and, from there, along to MGC 74 for signaling in turn to MSC 22.
  • the account-balance policy server 142 will remain within the SIP signaling path for the call ' being set up. Additional SIP messages used to set up the call, such as SIP 200 OK and SIP ACK messages, would pass between the SIP endpoints (e.g., MGC 74 and IP PBX server 40) through the account-balance policy server 142. Thus, the account- balance policy server 142 would see when the call is fully set up, such as when a SIP ACK passes between the endpoints. Further, SD? messages used to tear down the call, such as a SD? BYE message for instance, would also pass through the account-balance policy server 142, and so the account balance policy server would also see when the call ends.
  • SIP 200 OK and SIP ACK messages would pass between the SIP endpoints (e.g., MGC 74 and IP PBX server 40) through the account-balance policy server 142.
  • SD? messages used to tear down the call such as a SD? BYE message for instance, would
  • the account- balance policy server 142 will programmatically decrement the WCD's account balance.
  • the account-balance policy server 142 may then write the WCD's new account balance into the WCD's HSS profile record.
  • the account-balance policy server 142 can take a predefined action in response.
  • the account-balance policy server 142 can automatically tear down the call, such as by sending a SD? BYE to one or more of the SD? endpoints.
  • the account-balance policy server 142 can redirect the WCD to a balance refreshment platform (e.g., IVRU) such as by sending a SIP REDIRECT to the SIP signaling initiator.
  • the account balance policy server 100 can allow the existing call to complete normally and can then bar initiation of a new call due to the exhausted balance. Other examples are possible as well.
  • this account balance logic can be provided by SCP 32, using WIN prepaid triggers for instance.
  • the WCD's profile at SCP 32 can be provisioned with a value that indicates a number of allowed minutes of use of cellular-PBX integration service.
  • SCP 32 can then apply account balance logic to determine whether to direct MSC 22 to connect a call to media gateway system 70 in the first place and can decrement the account balance as the call proceeds.
  • MSC " 22 can then signal to the SCP, and the SCP can stop decrementing the WCD's account balance.
  • Figure 20 is a flow chart depicting an example set of functions that can be carried out to provide for account-balance based restriction on application of cellular-PBX integration service.
  • a quantity of cellular-PBX integration service is allotted to a WCD.
  • the quantity is decremented as the WCD uses the cellular- PBX integration service.
  • the WCD is precluded from using the cellular- PBX integration service in response to the quantity being exhausted. 12.
  • a switch such as MSC 22 will generate a call detail record (CDR) for each call that it handles, and the switch will send each CDR to a billing system, to facilitate billing of the WCD account holder.
  • the CDR typically identifies the WCD that placed or received the call, the directory number of the other party, and the duration of the call, among other information.
  • the cellular carrier could bill the WCD account holder for a call.
  • the cellular carrier could bill the WCD's associated IP PBX service provider (enterprise) for a call.
  • this issue can be resolved by billing cellular-PBX integration calls to the IP PBX service provider, and billing the WCD account holder (e.g., the WCD user personally) for non-cellular-PBX integration calls, (hi some instances, the same entity might be the IP PBX service provider (enterprise) and the WCD account holder; this exemplary embodiment can be applied even in that instance, to facilitate separate accounting for the two types of calls.)
  • SCP 32 provides a differential billing indicator in the intelligent network response message that it sends to the MSC 22 during call origination or termination.
  • the SCP may include (in a user-definable field or in some other MSC-discernable manner) a "personal" billing-indicator indicating that the WCD account holder should be billed for the call or an "enterprise” billing indicator indicating that the IP PBX service provider should be billed for the call.
  • the SCP when the SCP is directing the MSC to set up the call to media gateway system 70, the SCP can include an "enterprise" billing-indicator, whereas, when the SCP is directing the MSC to set up the call as a non-cellular-PBX integration call, the SCP can include a "cellular" billing-indicator.
  • the MSC can be programmed to treat a directive to set up the call to media gateway system 70 as an indication that the call is to be billed to one party (the enterprise) and a directive to set up the call conventionally as an indication that the call is to billed to another party (the WCD account holder).
  • the MSC 22 may then programmatically include in the CDR that it generates for the call a corresponding "personal" or “enterprise” billing indicator (in any predefined form).
  • a billing system that receives the CDR may record the call in the appropriate account, so as to bill the IP PBX service provider for cellular-PBX integration calls and the WCD account holder for other calls.
  • FIG. 21 is a flow chart depicting an example set of functions that can be carried out to provide for differential billing with cellular-PBX integration service.
  • request to set up a call to or from a WCD is received.
  • CSCF 100 various functions described above as being carried out by CSCF 100 in conjunction with one or more policy servers could be carried out by CSCF 100 alone, by MGC 74, or by one or more other entities involved with call setup and management.
  • various functions described above could be combined together or conducted in series.
  • the CSCE 100 can signal in series to multiple policy servers, in order to facilitate application of multiple policies related to cellular-PBX integration for a given call.
  • the SCP 32 can apply multiple polices related to cellular-PBX integration for a given call.
  • WCD can generally constitute a wireless subscriber, which can be a device and/or a user of the device.
  • a policy or state can be set or applied for a given user's WCD by setting or applying the policy or state for the given user, and a policy or state can be set or applied for a given user by setting or applying the policy or state for the given user's WCD.
  • Other examples are possible as well.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un système IP PBX qui dessert des téléphones d'entreprise par l'intermédiaire d'une connexion terrestre de réseau IP, ce système devant être étendu pour desservir des dispositifs de communication cellulaire sans fil (WCD) par l'intermédiaire d'un réseau d'accès radio (RAN) de porteuse cellulaire sans fil. Des appels reçus et émis par les dispositifs de communication cellulaire sans fil (WCD) sont reliés par le RAN de porteuse cellulaire et le système IP PBX, de sorte que ledit système IP PBX puisse commander et gérer les appels comme ce système IP PBX commanderait et gérerait les appels impliquant d'autres extensions dans le système IP PBX. Ainsi, un dispositif de communication cellulaire sans fil (WCD) devient une station client IP PBX, c'est-à-dire une extension du système IP PBX. A ce titre, le dispositif de communication cellulaire sans fil (WCD) peut bénéficier, en continu, de plusieurs des mêmes caractéristiques IP PBX dont bénéficient d'autres stations clients IP PBX plus traditionnelles (par exemple, standards téléphoniques). D'autres améliorations sont exposées dans la description de cette invention.
PCT/US2005/026583 2004-07-29 2005-07-27 Procede et dispositif pour etendre des services ip pbx a des dispositifs de communication cellulaires sans fil WO2006015013A2 (fr)

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US10/902,323 2004-07-29
US10/902,323 US7406330B2 (en) 2004-07-29 2004-07-29 Method and system for extending IP PBX services to cellular wireless communication devices
US11/135,946 2005-05-24
US11/136,116 US8060135B2 (en) 2004-07-29 2005-05-24 Method and system for selective application of cellular-PBX integration service
US11/135,899 US7260384B2 (en) 2004-07-29 2005-05-24 Method and system for dynamic selection of voice mail system
US11/135,946 US8254989B2 (en) 2004-07-29 2005-05-24 Method and system for account balance restriction on application of cellular-PBX integration service
US11/135,973 2005-05-24
US11/136,116 2005-05-24
US11/135,899 2005-05-24
US11/135,875 US8064951B2 (en) 2004-07-29 2005-05-24 Method and system for selective application of cellular-PBX integration service
US11/135,875 2005-05-24
US11/135,973 US8180393B2 (en) 2004-07-29 2005-05-24 Method and system for location-based restriction on application of cellular-PBX integration service

Publications (2)

Publication Number Publication Date
WO2006015013A2 true WO2006015013A2 (fr) 2006-02-09
WO2006015013A3 WO2006015013A3 (fr) 2006-03-23

Family

ID=35285432

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/026583 WO2006015013A2 (fr) 2004-07-29 2005-07-27 Procede et dispositif pour etendre des services ip pbx a des dispositifs de communication cellulaires sans fil

Country Status (1)

Country Link
WO (1) WO2006015013A2 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008051485A2 (fr) 2006-10-19 2008-05-02 Ascendent Telecommunications, Inc. Procédé et appareil à dispositif client permettant d'acheminer un appel
WO2008075938A2 (fr) * 2006-12-21 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Chevauchement à point de contrôle de service (scp) commandé entre gsm et ims
EP2028828A2 (fr) * 2007-08-21 2009-02-25 Avaya Inc. Réponse rapide à une entrée d'utilisateur dans un terminal de télécommunication
EP2105001A2 (fr) * 2006-09-29 2009-09-30 Nortel Networks Limited Mobilité d'entreprise
DE102008036499A1 (de) * 2008-08-05 2010-02-11 Siemens Ag Österreich Verfahren und Einrichtung zur Berechtigungsvergabe in einem Kommunikationsnetz
US8233491B2 (en) 2006-09-28 2012-07-31 Burns Jr James M Embedded media terminal adapter (EMTA) endpoint redirect mode
FR2977113A1 (fr) * 2011-06-24 2012-12-28 France Telecom Systeme de gestion de conference telephonique
US8363805B2 (en) 2006-06-22 2013-01-29 Burns Jr James M Media terminal adapter (MTA) initialization process display by use of an embedded caller name and caller identification
CN103179030A (zh) * 2013-03-28 2013-06-26 上海斐讯数据通信技术有限公司 一种家庭网关设备
US8526583B2 (en) 2006-09-29 2013-09-03 James M. Burns, JR. Media terminal adapter (MTA) local ringback option
US8675856B2 (en) 2006-08-01 2014-03-18 Cisco Technology, Inc. Media terminal adapter (MTA) routing of telephone calls based on caller identification information
US9692903B2 (en) 2005-10-31 2017-06-27 Genband Us Llc Network domain selection

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6073029A (en) * 1997-07-25 2000-06-06 U S West, Inc. Method and system for providing wireless communications to a subscriber of a private wireline network
WO2000078017A1 (fr) * 1999-06-14 2000-12-21 Wilshire Cellular, Inc. Procede et appareil pour communiquer avec l'un des dispositifs associes a un seul numero de telephone
US6285879B1 (en) * 1996-07-26 2001-09-04 Siemens Aktiengesellschaft Process and system for automatic routing
US20030013489A1 (en) * 2001-06-18 2003-01-16 Mar Jack K. Providing ip-based communications capabilities to mobile devices
US20040072593A1 (en) * 2002-10-10 2004-04-15 Robbins Barry R. Extension of a local area phone system to a wide area network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6285879B1 (en) * 1996-07-26 2001-09-04 Siemens Aktiengesellschaft Process and system for automatic routing
US6073029A (en) * 1997-07-25 2000-06-06 U S West, Inc. Method and system for providing wireless communications to a subscriber of a private wireline network
WO2000078017A1 (fr) * 1999-06-14 2000-12-21 Wilshire Cellular, Inc. Procede et appareil pour communiquer avec l'un des dispositifs associes a un seul numero de telephone
US20030013489A1 (en) * 2001-06-18 2003-01-16 Mar Jack K. Providing ip-based communications capabilities to mobile devices
US20040072593A1 (en) * 2002-10-10 2004-04-15 Robbins Barry R. Extension of a local area phone system to a wide area network

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9692903B2 (en) 2005-10-31 2017-06-27 Genband Us Llc Network domain selection
US10582061B2 (en) 2005-10-31 2020-03-03 Genband Us Llc Network domain selection
US8363805B2 (en) 2006-06-22 2013-01-29 Burns Jr James M Media terminal adapter (MTA) initialization process display by use of an embedded caller name and caller identification
US8675856B2 (en) 2006-08-01 2014-03-18 Cisco Technology, Inc. Media terminal adapter (MTA) routing of telephone calls based on caller identification information
US8233491B2 (en) 2006-09-28 2012-07-31 Burns Jr James M Embedded media terminal adapter (EMTA) endpoint redirect mode
EP2105001A4 (fr) * 2006-09-29 2014-06-04 Nortel Networks Ltd Mobilité d'entreprise
US8526583B2 (en) 2006-09-29 2013-09-03 James M. Burns, JR. Media terminal adapter (MTA) local ringback option
EP2105001A2 (fr) * 2006-09-29 2009-09-30 Nortel Networks Limited Mobilité d'entreprise
US8195163B2 (en) 2006-10-19 2012-06-05 Ascendent Telecommunications, Inc. Client device method and apparatus for routing a call
EP2078430A4 (fr) * 2006-10-19 2010-01-27 Ascendent Telecommunications I Procédé et appareil à dispositif client permettant d'acheminer un appel
EP2078429A2 (fr) * 2006-10-19 2009-07-15 Ascendent Telecommunications, Inc. Procédé et appareil à dispositif client permettant d'acheminer un appel
EP2824902A1 (fr) * 2006-10-19 2015-01-14 BlackBerry Limited Procédé et appareil de dispositif client de routage d'un appel
WO2008051485A2 (fr) 2006-10-19 2008-05-02 Ascendent Telecommunications, Inc. Procédé et appareil à dispositif client permettant d'acheminer un appel
EP2078430A2 (fr) * 2006-10-19 2009-07-15 Ascendent Telecommunications, Inc. Procédé et appareil à dispositif client permettant d'acheminer un appel
US8625576B2 (en) 2006-10-19 2014-01-07 Blackberry Limited Client device method and apparatus for routing a call
EP2078429A4 (fr) * 2006-10-19 2010-01-27 Ascendent Telecommunications I Procédé et appareil à dispositif client permettant d'acheminer un appel
US8554218B2 (en) 2006-10-19 2013-10-08 Blackberry Limited Client device method and apparatus for routing a call
US8233476B2 (en) 2006-12-21 2012-07-31 Telefonaktiebolaget Lm Ericsson (Publ) SCP-controlled overlay between GSM and IMS
WO2008075938A3 (fr) * 2006-12-21 2008-09-12 Ericsson Telefon Ab L M Chevauchement à point de contrôle de service (scp) commandé entre gsm et ims
US8446902B2 (en) 2006-12-21 2013-05-21 Telefonaktiebolaget Lm Ericsson (Publ) SCP-controlled overlay between GSM and IMS
WO2008075938A2 (fr) * 2006-12-21 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Chevauchement à point de contrôle de service (scp) commandé entre gsm et ims
EP2028828A3 (fr) * 2007-08-21 2009-08-19 Avaya Inc. Réponse rapide à une entrée d'utilisateur dans un terminal de télécommunication
US7991143B2 (en) 2007-08-21 2011-08-02 Avaya Inc. Rapid response to user input at a telecommunications terminal
EP2028828A2 (fr) * 2007-08-21 2009-02-25 Avaya Inc. Réponse rapide à une entrée d'utilisateur dans un terminal de télécommunication
DE102008036499A1 (de) * 2008-08-05 2010-02-11 Siemens Ag Österreich Verfahren und Einrichtung zur Berechtigungsvergabe in einem Kommunikationsnetz
FR2977113A1 (fr) * 2011-06-24 2012-12-28 France Telecom Systeme de gestion de conference telephonique
CN103179030A (zh) * 2013-03-28 2013-06-26 上海斐讯数据通信技术有限公司 一种家庭网关设备

Also Published As

Publication number Publication date
WO2006015013A3 (fr) 2006-03-23

Similar Documents

Publication Publication Date Title
US8169952B2 (en) Method and system for selective application of cellular-PBX integration service
US7260384B2 (en) Method and system for dynamic selection of voice mail system
US8180393B2 (en) Method and system for location-based restriction on application of cellular-PBX integration service
US8060135B2 (en) Method and system for selective application of cellular-PBX integration service
US8254989B2 (en) Method and system for account balance restriction on application of cellular-PBX integration service
US7406330B2 (en) Method and system for extending IP PBX services to cellular wireless communication devices
WO2006015013A2 (fr) Procede et dispositif pour etendre des services ip pbx a des dispositifs de communication cellulaires sans fil
US10034220B2 (en) System and method for enabling VPN-less session setup for connecting mobile data devices to an enterprise data network
US7380022B2 (en) Method and apparatus for transmitting wired data voice over IP data and wireless data through a common IP core network
US9622078B2 (en) Mobile application gateway for connecting devices on a cellular network with individual enterprise and data networks
US20180007608A1 (en) Call flow system and method for use in a legacy telecommunication system
US7206582B2 (en) Method, system and apparatus for call path reconfiguration
US7881449B2 (en) Enhanced call notification service
US7164762B2 (en) Enhanced call feature service
US8054960B1 (en) Method and system for setting up a ringback media session
US8059645B2 (en) Method and apparatus for providing E911 services via network announcements
JP2009506589A (ja) 移動体及びパケットベース呼制御
EP1487221A1 (fr) Déviation par un composant de serveur d'une portion d'un nouveau trajet média entre des portions d'un commutateur du service mobile commutées en mode paquet et en mode circuit
US8385232B1 (en) Flexible alerting for integrated cellular and VoIP
US8059800B1 (en) Method for viral distribution of ringback media
WO2006034364A2 (fr) Procede et appareil pour determination de sous-boite vocale fmfm sur ligne partagee, et duplication dynamique des appels partants et des acheminements dans un systeme telephonique
US20080240081A1 (en) Method, system and apparatus for providing rules-based restriction of incoming calls
US7945029B1 (en) Translation server for facilitating operations with multiple media messaging systems
US20100061365A1 (en) Method and apparatus for providing extension management in voice over internet protocol customer premises
US20050069104A1 (en) Call management service

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase