US20120129508A1

Movatterモバイル変換

Info

Publication number: US20120129508A1
Application number: US12/950,641
Authority: US
Inventors: William D. Gentry
Original assignee: Genband US LLC
Current assignee: Ribbon Communications Operating Co Inc
Priority date: 2010-11-19
Filing date: 2010-11-19
Publication date: 2012-05-24
Also published as: US9161190B2; US20130137410A1

Abstract

Description

TECHNICAL FIELD

The subject matter described herein relates to communications between fixed and mobile devices. More specifically, the subject matter relates to methods, systems, and computer readable media for unifying fixed and mobile devices via third party call control.

BACKGROUND

As the number of communications devices has increased, and with it the number of network identities associated with individual users, there exists an increased desirability for a single identity that can be used in sessions across all of a user's communication devices, both fixed and mobile, along with a consistent set of voice and multi-media applications that can be leveraged for all devices.

One conventional solution for providing such a single identity in SIP-based pre-IMS networks, as well as 3GPP-based IMS networks, includes having both the fixed and mobile devices register with the same application server. For example, all fixed and mobile clients may be required to register with SIP application servers using the same identity. However, this solution has several drawbacks such as inflexibility in the identities selectable by a user and interoperability difficulties between various types of networks and devices. Additionally, while third party call control interfaces currently exist on PBX and other end office nodes, these interfaces are not currently used to create a single identity for subscribers across both fixed and mobile devices.

Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for unifying fixed and mobile devices without excessive use of telephony resources.

SUMMARY

The subject matter described herein for unifying fixed and mobile devices via third party call control may be implemented using a non-transitory computer readable medium to having stored thereon executable instructions that when executed by the processor of a computer control the processor to perform steps. Exemplary non-transitory computer readable media suitable for implementing the subject matter described herein include chip memory devices or disk memory devices accessible by a processor, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single computing platform or may be distributed across plural computing platforms.

Terminology

As used herein, the term “third party call control” or “3PCC” refers to the ability of one entity to create a call/session in which communication is actually between other parties. In the traditional telephony context, third party call control allows one entity (i.e., the controller) to set up and manage a communications relationship or telephone call between two or more other parties. For example, third party call control may be used for operator services (where an operator creates a call that connects two participants together) and call conferencing. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP) and can include the traditional ones on the PSTN, but also new ones such as click-to-dial and next Generation 9-1-1. Click-to-dial allows a user to click on a web page to speak to a customer service representative. The web server then creates a call between the user and a customer service representative. The call can be between two phones, a phone and an IP host, or two IP hosts. Next Generation 9-1-1 allows for re-connection of a media stream to an alternate end point if the original destination end point becomes unavailable without dropping the original emergency call (which has a separate media stream to the 3PCC server). 3PCC is described in more detail in Ecma technical report (TR)-87, telephony application programming interface (TAPI), telephony server application programming interface (TSAPI), java telephony application programming interface (JTAPI) as well as the following Internet engineering task force (IETF) request for comments (RFCs): RFC 3261—SIP: Session Initiation Protocol, RFC 3312—Integration of Resource Management and Session Initiation Protocol (SIP), RFC 3725—Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP), RFC 4032—Update to the Session Initiation Protocol (SIP) Preconditions Framework, which are incorporated by reference herein in their entireties.

As used herein, the term “unified subscriber identity” refers to any type of unique address for a user, such as a directory number (DN). A unified subscriber identity may include an existing address, such as a user's home or work telephone number. A unified subscriber identity may encompass multiple identifiers or addresses associated with a user or device,

As used herein, the term “endpoint” refers to a point of termination (i.e., communications device) for a communications session, such as a landline telephone, SIP phone, mobile phone (cellular or otherwise).

As used herein, the term “fixed” refers to a state of being stationary, attached, established, or stable in terms of physical and/or logical location.

As used herein, the term “mobile” refers to a state of moving, capable of moving, or being moved from one location to another location.

As used herein, the term “node” is a connection point (communications device) in a communications network such as a redistribution point or a communication endpoint. A physical network node, therefore, is an active electronic device that is attached to a network, and is capable of sending, receiving, or forwarding information over a communications channel. In the fixed telephone network, a node may be a public or private telephone exchange, a remote concentrator, or a computer providing an intelligent network service. In cellular communication, switching points and databases such as the Base station controller, Home Location Register, Gateway GPRS Support Node (GGSN), and Serving GPRS Support Node (SGSN) are examples of nodes. Other exemplary nodes may include MSCs, STPs, SCPs, SSRs, and ASs.

As used herein, the term “originate” refers to the process of creating or bringing into being a call or session.

As used herein, the term “terminate” refers to the process of ending or concluding a call or session.

As used herein, the terms “deflect” “deflecting” and “deflection” refer to the process of diverting a call or session from a first destination endpoint to a second destination endpoint before the call or session is answered by the first destination endpoint:

As used herein, the term “transfer” refers to the process of diverting a call or session from a first destination endpoint to a second destination endpoint after the call or session is answered by the first destination endpoint.

As used herein, the term “grab” refers to the process of requesting the diversion or transfer of a call or session from a first destination endpoint to a second destination endpoint.

As used herein, the term “redirect” refers to any of: deflecting, transferring, and grabbing.

As used herein, the term “instruct” refers to signaling or communicating a task to be performed. For example, a first node may instruct a second node by sending one or more messages to the second node.

As used herein, the term “alert” refers to the process of a device performing an action intended to make the user aware of a session (e.g., ringing) when the session is offered to a device associated with the user.

As used herein, the term “page” refers to the process of locating a registered mobile client within the radio access network.

As used herein, the term “service” refers to a set of related software functionality, together with the policies that control its usage. Services may be deployed and used on the Internet (or private IP networks) and may also be accessed from traditional circuit switched networks. Exemplary services include voice over IP (VoIP), IP television (IPTV), presence, instant messaging, and location-based services.

As used herein, the term “registration” refers to a representation of a dynamic piece of state information maintained by the network. A registrar is a server that accepts registrations from users and stores the registrations in a database known as a location service database.

As used herein, the terms “register” and “registering” refer to the process of recording or associating a user with a particular location and/or IP address in a database. Registering allows a user agent to create, modify, and delete registrations.

As used herein, the term “session” refers to a packet stream compatible with the session initiation protocol (SIP). Exemplary packet streams may include real time transport protocol (RTP) packets for carrying voice and/or video content.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter described herein will now be explained with reference to the accompanying drawings of which:

FIG. 1 is a system diagram showing exemplary components for unifying fixed and mobile devices via third party call control according to an embodiment of the subject matter described herein;

FIG. 2 is a flow chart showing an exemplary process for terminating a session to one of a fixed and a mobile device via unified third party call control according to an embodiment of the subject matter described herein;

FIG. 3 is a message sequence diagram showing an exemplary process for unifying fixed and mobile devices via third party call control where the mobile device answers the session according to an embodiment of the subject matter described herein;

FIG. 4 is a message sequence diagram showing an exemplary process for unifying fixed and mobile devices via third party call control via third party call control where the fixed device answers the session according to an embodiment of the subject matter described herein;

FIG. 5 is a flow chart showing an exemplary process for unifying fixed and mobile devices via third party call control for a session originating from a unified subscriber identity according to an embodiment of the subject matter described herein;

FIG. 6 is a flow chart showing an exemplary process for grabbing a call/session by a fixed endpoint from a mobile device according to an embodiment of the subject matter described herein;

FIG. 7 is a message sequence diagram showing an exemplary process for a mobile device grabbing a call/session from a fixed endpoint according to an embodiment of the subject matter described herein; and

FIG. 8 is a message sequence diagram showing an exemplary process for a fixed endpoint grabbing a call/session from a mobile device according to an embodiment of the subject matter described herein.

DETAILED DESCRIPTION

The subject matter described herein includes methods, systems, and computer readable media for unifying fixed and mobile devices via third party call control. This includes maintaining a single identity across multiple fixed and/or mobile devices including fixed (VoIP or TDM) endpoints that are not registered with a SIP application server. Such endpoints can include endpoints associated with PBX nodes within corporate networks, soft switches which host VoIP and TDM endpoints, and traditional telephony TDM end offices. The subject matter described herein accomplishes this by integrating third-party call control interfaces with offboard application servers to allow the user to leverage a single set of screening/routing services for all devices, extend a session to a mobile, and instruct the node which hosts the fixed device to deflect the call to the application server for final connection establishment. For example, an application server logically sitting above all other network nodes necessary for connecting the various fixed and mobile endpoints that may be associated with the user may be specially dedicated for the purpose of performing unified third party call control. Moreover, users may designate one of their existing subscriber identifiers (e.g., their home telephone number) as their unified subscriber identity used to unify all of their services, where the user's other subscriber identifiers (e.g., SIP URI, email address, work telephone number, etc.) may be associated with the unified subscriber identifier in the dedicated AS. According to other embodiments, the subject matter described herein also provides for an existing session to be grabbed from one device to the other as needed by the subscriber. Specific non-limiting examples of various embodiments will now be described in greater detail below.

System

FIG. 1 is a system diagram showing exemplary components for unifying fixed and mobile devices via third party call control according to an embodiment of the subject matter described herein. Referring toFIG. 1, fixedendpoint100 may include a conventional landline telephone and may be associated with a first subscriber. It may be appreciated that fixedendpoint100 can leverage any one of a variety of access interfaces (e.g., VoIP or TDM-based).

Signaling node

102 may support a third-party call control interface and host fixedendpoint100.Signaling node102 may take the form of a public branch exchange (PBX),class 5 end office switch, call server, soft switch, or telephony time division multiplexed (TDM) node. A single identity may be defined (i.e., unified subscriber identity), on signalingnode102 which hosts fixedendpoint100, for each user from among a plurality of users. This single identity typically takes the form of a directory number (DN), but may include any type of unique address for the user.

Fixed endpoint

104 may be the same as fixedendpoint100 with the exception that fixedendpoint104 may be associated with a different subscriber and, therefore, may be served by a different signaling node.

SIP application server

106 is a network communications node that hosts and executes services, and may interface with one or more S-CSCFs using SIP. An application server may be used to provide uniform services across the fixed endpoint and mobile endpoint. The application server leverages the 3PCC interface to register interest in a specific endpoint and receive notifications whenever telephony sessions originate or terminate to the fixed endpoint. The application server may leverage the 3PCC interface to request notification events whenever a session originates or terminates to the fixed endpoint, as well as progress of such sessions.

The 3PCC interface can take any one of several forms, including TR-87 and TAPI-based 3PCC interfaces.

Public switched telephone network (PSTN)108 is circuit-switched network collection of interconnected public telephone networks that was designed primarily for voice traffic.

Mobile switching center (MSC)110 is the primary service delivery node for GSM/CDMA and is responsible for routing voice calls and SMS as well as other services.MSC110 may be responsible for setting up and releasing end-to-end connections, handling mobility and hand-over requirements during calls, and taking care of charging and real time pre-paid account monitoring. It may be appreciated that the subject matter described herein may be applied to both pre-IMS and IMS configurations where the mobile device is accessed via an IMS core network.

Mobile device

112 may include a cellular telephone, smart phone, PDA, or similar mobile communications endpoint. It is appreciated that a single subscriber may be associated with multiple endpoints, such as fixed endpoint100 (work phone) and mobile device112 (cell phone).

Media server

114 may refer to a device configured to provide a variety of functions. A media resource function (MRF) may provide media related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements. Each MRF may be further divided into a media resource function controller (MRFC) and a media resource function processor (MRFP). The MRFC may include a signaling plane node that interprets information received from an AS and S-CSCF to control the MRFP. The MRFP may include a media plane node used to mix, source, or process media streams as well as to manage access rights to shared resources. The media resource broker (MRB) may include a functional entity that is responsible for both collection of appropriate published MRF information and supplying of appropriate MRF information to consuming entities such as the AS. The MRB can be used in two modes: query mode and in-line mode. For query mode, the AS may query the MRB for media and, using the response of MRB, may set up the call. For in-line mode, the AS may send a SIP INVITE to the MRB and the MRB may set up the call.

Internet protocol (IP)network116 is a network that uses the IP protocol, which is part of the TCP/IP protocol suite. This includes the Internet, private LANs, and other packet-switched data and voice networks.

Softswitch/gateway118 is a central device in a telecommunications network which connects telephone calls from one phone line to another, entirely by means of software running on a computer system. This work was formerly carried out by hardware, with physical switchboards to route the calls. A softswitch is typically used to control connections at the junction point between circuit and packet networks

First subscriber

120 may include a user capable of using an endpoint in order to communicate with other users (via other endpoints) in a communications network. It may be appreciated thatfirst subscriber120 may be associated with a plurality of both mobile and fixed communications devices. For example,first subscriber120 may be associated with a home landline telephone having a fixed home telephone number, a home cellular phone having a mobile home number, a work VoIP phone having a fixed work number, and a work Blackberry™ having a mobile work number.

Base transceiver station (BTS)122 facilitates wireless communication between user equipment (UE) and a network. UEs are devices like mobile phones (handsets), WLL phones, computers with wireless Internet connectivity, WiFi and WiMAX gadgets etc. The network can be that of any of the wireless communication technologies like GSM, CDMA, WLL, WAN, WiFi, WiMAX etc. BTS is also referred to as the radio base station (RBS), node B (in 3G Networks) or, simply, the base station (BS).

Base station controller (BSC)124 handles allocation of radio channels, receives measurements from the mobile phones, and controls handovers from BTS to BTS (except in the case of an inter-BSC handover in which case control is in part the responsibility of the anchor MSC). A single BSC may have tens or even hundreds of BTSs under its control. One function ofBSC124 may be to act as a concentrator where many different low capacity connections to BTSs (with relatively low utilization) become reduced to a smaller number of connections towards the mobile switching center (MSC) (with a high level of utilization).BSC124 may also provide all the required data to the operation support subsystem (OSS) as well as to the performance measuring centers.

Second subscriber

126 may include a user similar tofirst subscriber120 described above. However, it may be appreciated thatsecond subscriber126 may belong to different (or the same) network(s) asfirst subscriber120 and may be associated with different devices and/or subscriber identifiers (e.g., telephone numbers, URIs, etc.)

Terminations to a Unified Subscriber Identity

FIG. 2 is a flow chart showing an exemplary process for terminating a session between unified fixed and mobile devices via third party call control according to an embodiment of the subject matter described herein. Referring toFIG. 2, atstep200, a network signaling node may be monitored for events associated with a unified subscriber identifier. For example, an application server may request notification of (e.g., subscribe to) events such as reception of a SIP INVITE message associated with some subscriber identifiers served by a signaling node (e.g., a public branch exchange (PBX) orclass 5 end office) but not other subscriber identifiers.

Atstep202, the session may be routed to a unified subscriber identity, which may cause the session to terminate at the node which hosts the fixed device associated with the unified subscriber identity. For example, originating endpoint may create a session addressed to DN +1-202-533-1234 which is terminated atnode102.

Atstep204, signalingnode102 may determine whether an application server has registered to receive notification of (i.e., registered interest in) termination events for the unified subscriber identity. If no application server has registered to receive notification of termination events for the subscriber associated with the session, control may proceed to step206 where the session may be processed normally. However, if the session is associated with a unified subscriber identifier for which an application server has registered to receive notification of termination events, control may proceed to step208.

Atstep208, using the 3PCC protocol, the signaling node (e.g., PBX orclass 5 end office) may generate) a termination event notification which may be communicated toapplication server106. Atstep210, the notification of the termination event associated with the subscriber identified by the unified subscriber identifier served by signalingnode102 may be received byapplication server106. In this example, becauseapplication server106 has registered withnode102 requesting notification of termination events associated with DN +1-202-533-1234, signalingnode102 may send termination event notification toapplication server106 indicating that a session addressed to DN +1-202-533-1234 has been received.

Atstep212, upon receiving the termination event notification,application server106 may execute screening and routing logic in order to determine how the session should ultimately terminate and whether it should be forked to multiple destinations. Depending on the capabilities of the 3PCC protocol,application server106 may proceed to offer the session to the fixed endpoint, or may suspend the session for a short period of time in order to giveapplication server106 the opportunity to execute services. Unlessapplication server106 responds otherwise, the session may be offered to the fixed endpoint, and alerting is provided to the fixed endpoint. In one embodiment,application server106 may create a new call session to the subscriber's mobile endpoint by leveraging the DN of the mobile endpoint. This session may be routed byapplication server106 to the wireless network which serves the subscriber's mobile endpoint.Mobile device112 may be paged and alerted. At this point, both subscriber's fixedendpoint104 andmobile endpoint112 are alerting.Application server106 may also leveragemedia server114 to generate comfort noise, tone, or announcement that may eventually be connected tomobile endpoint112 when it answers. This will alert the subscriber that a call is being delivered to their device during the short interval when the final connection is being negotiated.

Atstep214, if the fixed device answers the session, an answer notification may be delivered using a 3PCC protocol interface toapplication server106. Upon receiving the answer notification,application server106 may release the session to the subscriber's mobile device. Signaling messages may be sent to all of the terminating endpoints other than the terminating endpoint used to answer the call for instructing the terminating endpoints to release resources associated with the offered call. For example, fixedendpoint104 may deliver answer notification message toapplication server106 and, in response,application server106 may send a session Release message tomobile endpoint112. It may be appreciated that theapplication server106 may continue to maintain state information for the active session so that it can be made visible to services running on application server106 (such as presence-based services).

Atstep216, ifmobile device112 answers the session,application server106 may detect the answer signal and may begin to establish a media connection between fixedendpoint100 andmobile device112. It may be appreciated that while this connection is being formed, the subscriber may be connected to comfort tones or announcements generated bymedia server114.

Establishment of a media connection may involveapplication server106 using the 3PCC interface to instruct signalingnode102 to deflect the session away from fixedendpoint104 and instead route it to a temporary location DN (TLDN) provided byapplication server106. This TLDN may be managed as a pooled resource byapplication server106, and may be temporarily associated with the specific session. For example,application server106 may detect answer signal frommobile endpoint112 and, in response, send a deflect session message that includes TLDN +1-808-577-9876 to fixedendpoint104.Node102 may respond by deflecting the session. The alerting session to fixedendpoint104 may be released, and the call may be redirected to the TLDN provided byapplication server106. The TLDN may be routed through the interconnect network toapplication server106. The interconnect network can take any one of a variety of forms, including for example public switched telephone network (PSTN)108 or a private network. When the redirected call arrives atapplication server106, the TLDN may be used to correlate it to the session that was previously created formobile device112.Application server106 may then negotiate an end-to-end media path between fixed

endpoints

100 and104. The state of the active session may be maintained byapplication server106 and may be represented to other services running on the server (e.g., presence-based services).

FIG. 3 is a message sequence diagram showing an exemplary process for terminating a session between unified fixed and mobile devices via third party call control according to an embodiment of the subject matter described herein. Referring toFIG. 3, atstep300,application server106 may begin monitoring fixed endpoints connected to, served by, or otherwise associated with signalingnode102 via the 3PCC interface.

Atstep302, fixedendpoint100 makes a call todestination subscriber126, as identified by his or her unified subscriber identifier.

Atstep304, fixedendpoint100 may send a call setup message to signalingnode102 that includes the unified subscriber identifier forsubscriber126.

Atstep306, in response to receiving the Setup message, signalingnode102 may send a termination event message to application server106 (which was requested byapplication server106 in step300).

Atstep308, signalingnode102 may send a setup message to fixedendpoint104 in an attempt to connect the call.

Atstep310, routing logic forsubscriber126 may be executed onapplication server106.

Atstep312, fixedendpoint104 may perform DN2 alerting. For example, the endpoint begins to ring in order to notify the user of the incoming call or session.

Atstep314,application server106 may send a first SIP INVITE message toPSTN108 destined for a mobile DN associated with the unified subscriber identity.

Atstep316, the first INVITE message may be forwarded fromPSTN108 toMSC110 and ultimately, for delivery to the mobile subscriber. Atstep318,application server106 may initiate a session to one or more additional PSTN destinations, such as the user's home phone or some other device the user would also like the call to be offered to.

Atstep320,application server106 may send a second SIP INVITE message toPSTN108 that is addressed to another PSTN node, such asPSTN node114.

Atstep322, the second INVITE message may be forwarded byPSTN108 toother PSTN node114.

In the scenario shown inFIG. 3, the called user chooses to answer the call using his or her fixed endpoint. Therefore, atstep324, fixedendpoint104 may send an Answer message to signalingnode102 and, atstep326, signalingnode102 may return an Answer event message toapplication server106.

Atstep328,application server106 may begin the process of clearing all other call legs, which are not needed becausesubscriber126 has answered using fixedendpoint104. For example, atstep330,application server106 may send a first CANCEL message toPSTN108 for canceling the call tomobile device112. Atstep332, the CANCEL message is forwarded byPSTN108 toMSC110 and, atstep334, MSC may formulate and deliver a Release message tomobile device112. Additionally,application server106 may send a second CANCEL message destined forPSTN node114 for canceling the comfort noise, tone, or announcement services that are no longer needed. For example, atstep336,application server106 may send the second CANCEL message toPSTN108 which, atstep338, may forward the second CANCEL message toPSTN node114.

Atstep340, application server may optionally maintain call state information for subsequent call grabs.

Becausesubscriber126 has answered the call usingfixed endpoint104, atstep342, a media path may be established between callingfixed endpoint100 and called fixedendpoint104. When the call is completed,subscriber120 may hang up and begin the process of tearing down the call. For example, atstep344, fixedendpoint100 may send a Release message to signalingnode102 and, atstep346, signalingnode102 may send a Release event message toapplication server106. In response, atstep348,application server106 may store an indication Presence=Idle. Finally, atstep350, signalingnode102 may send a Release message to fixedendpoint104 and the call may be ended.

FIG. 4 is a message sequence diagram showing an exemplary process for terminating a session between unified fixed and mobile devices via third party call control according to an embodiment of the subject matter described herein. Referring toFIG. 4, it may be appreciated that steps400-420 are the same as steps300-320 inFIG. 3. However, in contrast to the scenario illustrated inFIG. 3 wheresubscriber120 answered the call using his or her fixed endpoint, inFIG. 4

subscriber

120 answers the call from his or her mobile device. For example, atstep400,application server106 may begin monitoring fixed endpoints connected to, served by, or otherwise associated with signalingnode102 via the 3PCC interface.

Atstep402, fixedendpoint100 makes a call todestination subscriber126, as identified by his or her unified subscriber identifier.

Atstep404, fixedendpoint100 may send a call setup message to signalingnode102 that includes the unified subscriber identifier forsubscriber126.

Atstep406, in response to receiving the Setup message, signalingnode102 may send a termination event message to application server106 (which was requested byapplication server106 in step400).

Atstep408, signalingnode102 may send a setup message to fixedendpoint104 in an attempt to connect the call.

Atstep410, routing logic forsubscriber126 may be executed onapplication server106.

Atstep412, fixedendpoint104 may perform DN2 alerting. For example, the endpoint begins to ring in order to notify the user of the incoming call or session.

Atstep414,application server106 may send a first SIP INVITE message toPSTN108 destined for a mobile DN associated with the unified subscriber identity.

Atstep416, the first INVITE message may be forwarded fromPSTN108 toMSC110 and ultimately, for delivery to the mobile subscriber.

Atstep418,MSC110 may send a Setup message tomobile device112.

Atstep420,application server106 may send a second SIP INVITE message to initiate a session to one or more additional PSTN destinations, such as the user's home phone or some other device the user would also like the call to be offered to. Atstep422, the INVITE message is forwarded byPSTN108 toPSTN node114 for providing these services.

As mentioned above, in contrast to the scenario shown inFIG. 3,subscriber126 may answer the call at his or her mobile device. Therefore, atstep424,mobile device112 may send an Answer message toMSC110.

Atstep426,MSC110 may send a200 OK message toPSTN108 andPSTN108 may, atstep428, forward the200 OK message toapplication server106.

Atstep430,application server106 may cancel other call legs or landline-associated call signaling because they are no longer needed. For example,application server106 may send a CANCEL message toPSTN108 and, atstep432,PSTN108 may forward the CANCEL message toPSTN node114.

Atstep434,application server106 may deflect the call tomobile device112 by sending a Deflect Call message including an International mobile routing number (IMRN) toPBX102.

Atstep436, signalingnode102 may send a Release message to fixedendpoint104 and, atstep438,PBX102 may redirect the call to the IMRN provided earlier. In a SIP embodiment, signalingnode102 may send a SIP INVITE message including the IMRN toPSTN108. However, any suitable PBX protocol, such as primary rate interface (PRI), Q signaling (QSIG), and H.323 may also be used without departing from the scope of the subject matter described herein.

Atstep440,PSTN108 may forward the INVITE message toapplication server106 and, atstep442,application server106 may negotiate an end-to-end media path between fixedendpoint100 andsubscriber126 atmobile device112. Finally, atstep444, the media path has been established between the two endpoints and the call/session may be conducted (call/session teardown signaling messages omitted for simplicity).

Session Originating from a Unified Subscriber Identity

FIG. 5 is a flow chart showing an exemplary process for unifying fixed and mobile devices via third party call control for a session originating from a unified subscriber identity according to an embodiment of the subject matter described herein. Referring toFIG. 5, atstep500, a network signaling node may be monitored for events associated with a unified subscriber identifier. For example, an application server may request notification of (e.g., subscribe to) events such as reception of a SIP INVITE message associated with some subscriber identifiers served by a signaling node (e.g., a public branch exchange (PBX) orclass 5 end office) but not other subscriber identifiers.

Atstep502, a session may be originated from a fixed device associated with a unified subscriber identifier hosted by a network signaling node. The subscriber can originate a new session using any fixed or mobile device which shares the identity.

Atstep504, it is determined whether an application server has registered interest in origination events for the subscriber associated with the unified subscriber identity.

If the session is not originated by a fixed device associated with a subscriber identifier for which an application server has registered interest in origination events, control may proceed to step506 where the session may be processed normally. This may include routing the session to a destination mobile device.

However, if the session is not originated by a fixed device associated with a subscriber identifier for which an application server has registered interest in origination events, control may proceed to step508. Atstep508, an origination event notification may be communicated to the application server using the 3PCC protocol. For example, sessions originating from the fixed device may be processed by the node which hosts the fixed device using existing call setup routines. As a part of the origination, an origination event notification may be communicated using the 3PCC protocol to the application server. The application server may maintain this state information and represent it to other services running on the server (such as presence-based services).

Atstep510, in response to receiving the origination event notification, the signaling node may redirect the session from the mobile device to the application server. Sessions originating from the mobile device may be redirected to the application server so that they can be processed using the single identity of the subscriber. It may be appreciated that, by redirecting sessions to the application server, the terminating party is not aware of the specific device which the subscriber uses to create the call. Several methods exist for redirecting a call to an application server. These include leveraging a software application (client) running on the mobile device to redirect the call, using an intelligent network (IN)-based service node to redirect the origination to the application server, or using translations and routing services defined natively within the wireless carrier's network to route the call.

Call Grabbing

Once the subscriber has an active session on one device, the subscriber may move or “grab” the call to a different device by leveraging a call grabber service. Call grabber service may be provided by SIP application server(s) and work between clients registered on the server. The call grabber service can be leveraged when the fixed endpoint is hosted by other telephony nodes, such as a PBX, a softswitch, or an end-office telephony node.

FIG. 6 is a flow chart showing an exemplary process for grabbing a call/session by a fixed endpoint from a mobile device according to an embodiment of the subject matter described herein. Referring toFIG. 6, atstep600, an active session is provided on at least one of a fixed device and a mobile device. It may be appreciated that as a precondition to performing a call grab, an active session exists and the application server has received state notifications of the session via the 3PCC interface.

Atstep602, it may be determined whether the subscriber desires to move the call or session to a different device than the one currently used for conducting the call. If it is determined that the subscriber does not wish to move the call to another device, then control may proceed to step604 where the call may proceed normally using the existing device.

However, if the subscriber wishes to move the call to another device, which may be associated with the current device via the unified subscriber identity, control may proceed to step606. Atstep606, a call grabber service that is provided by one or more application servers may be initiated. In one potential embodiment, the call grabber service may be initiated by entering a service code on the device to which the call is to be moved (grabbed). If the call grabber service code is entered on the fixed device, a notification may be sent via the 3PCC interface to the application server to inform it of the service request. The application server may then allocate a TLDN and direct the fixed device's node (via a 3PCC response) to deflect the session to the specified TLDN. The fixed device's node may respond by redirecting the call to the TLDN, which ultimately routes to the application server.

Alternatively, if the call grabber service code is entered on the mobile device, call redirection may be handled using the method outlined above for originating sessions from a single identity. Through this method, the call is ultimately routed to the application server.

Atstep608, whenapplication server106 receives the incoming call grabber session, it may correlates the incoming call grabber session to the active session that is to be grabbed. When invoked from a fixed device, the TLDN may be correlated to the state information stored with the initial 3PCC notification. This identifies the subscriber, which the application server can use to locate the active session. Alternatively, when invoked from a mobile device, the calling line identification (CLI) may identify the mobile DN, which can be correlated to the endpoint's active session.Application server106 may use the mobile DN to locate the active session.Application server106 may allocate a TLDN and leverage the 3PCC interface to instruct the node associated with the fixed device identified by the DN to perform a single-step transfer to the TLDN. The fixed device's node may respond by performing the transfer and result in the application server having direct control of the initial call.

Atstep610, the application server may then negotiate an end-to-end media path between the remote party and the device that is grabbing the call.

Atstep612, the subscriber's other device, which was previously connected to the session, may be released. It may also be appreciated that a call may be grabbed multiple times between fixed and mobile devices by repeating the method described above.

FIG. 7 is a message sequence diagram showing an exemplary process for a mobile device grabbing a call/session from a fixed endpoint according to an embodiment of the subject matter described herein. Referring toFIG. 7, atstep700,application server106 may begin monitoring fixed endpoints connected to, served by, or otherwise associated with signalingnode102 via the 3PCC interface.

Atstep702, fixedendpoint100 makes a call todestination subscriber126, as identified by his or her unified subscriber identifier.

Atstep704, fixedendpoint100 may send a call setup message to signalingnode102 that includes the unified subscriber identifier forsubscriber126.

Atstep706, in response to receiving the Setup message, signalingnode102 may send a termination event message to application server106 (which was requested byapplication server106 in step700).

Atstep708, signalingnode102 may send a setup message to fixedendpoint104 in an attempt to connect the call.

Atstep710, fixedendpoint104 may perform DN2 alerting. For example, the endpoint may begin to ring in order to notify the user of the incoming call/session.

Atstep712, fixedendpoint104 may send an Answer message toPBX102.

Atstep714, signalingnode102 may send an Answer event message toapplication server106.

Atstep716,application server106 may maintain call state information for a subsequent call grab.

Atstep718, a media path may be established betweenfixed endpoint100 andfixed endpoint104.

Atstep720, a call grab request may be received (from subscriber126) originating frommobile device112.

Atstep722,application server106 may send an IP multimedia routing number (IMRN) tomobile device112 in response to the call grab request. The IMRN is a routable number that points to IMS and has the same structure as an international ISDN number. When a call is originated by a user equipment (UE) device in a circuit switched network (e.g., PSTN108), appropriate call information associated with the call may be provided to a CCCF network node disposed in the IMS network. At the CCCF node, a pool of E.164 numbers may be maintained as IMRNs which are mapped to, or otherwise associated with, called party numbers. In addition to the IMS-based embodiment shown, it is appreciated that the subject matter described herein may also be applied to pre-IMS networks and that the IMS routing scenario illustrated inFIG. 7 is not intended to be limiting.

Atstep724,mobile device112 may send a call Setup message that includes the IMRN toMSC110.

Atstep726,MSC110 may forward the Setup message including the IMRN toPSTN108 and, atstep728,PSTN108 may formulate and send a SIP INVITE message including the IMRN toapplication server106.

Atstep728,application server106 may send a Single Step Transfer message, for transferringsubscriber126 to the IMRN, toPBX102. It is appreciated that while an IMRN (or similar mechanism) may be used both for routing call betweenMSC110 andapplication server106, as well as betweenapplication server106 andPBX102, this does not necessarily mean that the IMRN has to be the same in both cases.

Steps

726 and728 may be independent of one another.

In response, atstep730, signalingnode102 may send a Release message to fixedendpoint104.

Additionally, atstep732, signalingnode102 may send an INVITE message including the IMRN toPSTN108.

Atstep734,PSTN108 may forward the INVITE message including the IMRN toapplication server106.

At

steps

736 and738,application server106 may negotiate an end-to-end media path between fixedendpoint100 and (subscriber126 at)mobile device112.

FIG. 8 is a message sequence diagram showing an exemplary process for a fixed endpoint grabbing a call/session from a mobile device according to an embodiment of the subject matter described herein. Referring toFIG. 8, atstep800, fixedendpoint104 may send a Setup message to signalingnode102 that includes a Call grab service code.

Atstep802, signalingnode102 may send an INVITE message, including the call grab service code, toPSTN108 and, atstep804,PSTN108 may forward the INVITE message toapplication server106.

Atstep806,application server106 may begin the process of releasing the call leg to the mobile device.

Atstep808,application server106 may begin the process of negotiating an end-to-end media path.

The call leg release process referenced instep806 may begin, atstep810, whenapplication server106 sends a Release message toPSTN108. Atstep812,PSTN108 may forward the Release message toMSC110 and, atstep814,MSC110 may forward the Release message tomobile device112.

The media path negotiation process referenced instep808 may result in, atstep816, a media path being established betweenfixed endpoint100 and fixed endpoint104 (becausesubscriber126 grabbed the call using their fixedendpoint104 in this scenario).

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.

Claims

1. A method for unifying fixed and mobile devices via third party call control, the method comprising:

at an application server (AS) that supports a third-party call control (3PCC) interface:

detecting a call addressed to a unified subscriber identifier associated with a terminating subscriber, wherein the terminating subscriber is associated with two or more terminating endpoints;

offering the call to each of the terminating endpoints by initiating signaling to each of the terminating endpoints using the 3PCC interface;

detecting one of the terminating endpoints used to answer the call;

redirecting the call to the terminating endpoint used to answer the call; and

sending signaling messages to all of the terminating endpoints other than the terminating endpoint used to answer the call for instructing the terminating endpoints to release resources associated with the offered call.

2. The method ofclaim 1 wherein offering the call to the two more terminating endpoints includes offering the call to at least one of a mobile endpoint and a fixed endpoint.

3. The method ofclaim 1 comprising paging and alerting at least one of the terminating endpoints.

4. The method ofclaim 1 comprising maintaining state information for the session such that the state information is visible to services running on the application server.

5. The method ofclaim 1 wherein detecting a call includes detecting an active call originating at an originating endpoint and terminating at a first terminating endpoint of the two or more terminating endpoints.

6. The method ofclaim 5 wherein offering the call to each of the terminating endpoints includes receiving an indication that the terminating subscriber wishes to terminate the call at a second terminating endpoint being different from the first terminating endpoint.

7. The method ofclaim 6 comprising, in response to receiving the indication that the terminating subscriber wishes to terminate the call at the second terminating endpoint:

initiating a call grabber service for invoking a call grabber session;

correlating the incoming call grabber session to the active call;

negotiating an end-to-end media path between the originating subscriber and the second terminating endpoint; and

sending signaling messages to the first terminating endpoint for instructing the first terminating endpoint to release resources associated with the offered call.

8. The method ofclaim 6 wherein receiving the indication that the terminating subscriber wishes to terminate the call at a second terminating endpoint includes receiving a service code from the second terminating endpoint.

9. The method ofclaim 8 comprising allocating a temporary location directory number (TLDN) to the call grabber session and instructing a signaling node to deflect the call grabber session to the specified TLDN.

10. The method ofclaim 1 comprising registering interest in termination or origination events by an endpoint associated with the unified subscriber that includes requesting notification of events whenever a session originates or terminates to the endpoint associated with the unified subscriber identifier.

11. An application server for unifying fixed and mobile devices via third party call control, the application server comprising:

a third-party call control (3PCC) interface for:

offering the call to each of the terminating endpoints by initiating signaling to each of the terminating endpoints; and

detecting one of the terminating endpoints used to answer the call;

a communications module for:

redirecting the call to all of the terminating endpoint used to answer the call; and

12. The application server ofclaim 10 wherein the 3PCC interface is configured to offer the call to at least one of a mobile endpoint and a fixed endpoint.

13. The application server ofclaim 10 wherein the 3PCC interface is configured to page and alert at least one of the terminating endpoints.

14. The application server ofclaim 10 wherein the 3PCC interface is configured to maintain state information for the session such that the state information is visible to services running on the application server.

15. The application server ofclaim 10 wherein the 3PCC interface is configured to detect an active call originating at an originating endpoint and terminating at a first terminating endpoint of the two or more terminating endpoints.

16. The application server ofclaim 15 wherein the 3PCC interface is configured to receive an indication that the terminating subscriber wishes to terminate the call at a second terminating endpoint being different from the first terminating endpoint.

17. The application server ofclaim 16 wherein the 3PCC interface, in response to receiving the indication that the terminating subscriber wishes to terminate the call at the second terminating endpoint, is configured to:

initiate a call grabber service for invoking a call grabber session;

correlate the incoming call grabber session to the active call; and

the communications module is configured to:

negotiate an end-to-end media path between the originating subscriber and the second terminating endpoint; and

send signaling messages to the first terminating endpoint for instructing the first terminating endpoint to release resources associated with the offered call.

18. The application server ofclaim 17 wherein the indication that the terminating subscriber wishes to terminate the call at the second terminating endpoint comprises a service code from the second terminating endpoint.

19. The application server ofclaim 10 wherein the communications module is configured to communicate with one of a private branch exchange (PBX), a softswitch, and an end-office telephony node.

20. The application server ofclaim 10 wherein the 3PCC interface includes one of a technical report (TR)-87 interface and a telephony application programming interface (TAPI)-based interface.

21. The application server ofclaim 10 wherein the application server provides uniform services for the unified subscriber identity.

22. The application server ofclaim 10 wherein the unified subscriber identifier includes one of a directory number (DN) and a uniform resource identifier (URI).

23. The application server ofclaim 10 wherein the 3PCC interface is configured to register interest in termination or origination events by an endpoint associated with the unified subscriber that includes requesting notification of events whenever a session originates or terminates to the endpoint associated with the unified subscriber identifier.

24. A computer readable medium comprising computer executable instructions embodied in a non-transitory computer readable medium and when executed by a processor of a computer performs steps comprising:

at a dedicated application server (AS) that supports a third-party call control (3PCC) interface:

detecting one of the terminating endpoints used to answer the call;

redirecting the call to the terminating endpoint used to answer the call; and