Mobile device call management with multiple over-the-top calls

A mobile device executes an operating system (OS) call manager and an over-the-top (OTT) calling application. The OTT calling application receives a notification for a first OTT call, and notifies the OS call manager of the first OTT call. The OS call manager assigns shared device resources of the mobile device to the first OTT call. The OTT calling application receives a notification for a second OTT call, and sends, to an OTT Telephony Application Server (TAS) without notifying the OS call manager of the second OTT call, a request to switch from the first OTT call to a second OTT call. The OTT calling app identifies the first OTT call as inactive and the second OTT call as active, and allocates the shared device resources assigned to the first OTT call to the second OTT call.

BACKGROUND

Over-the-top (OTT) services involve services that ride on top of an existing network service provided by a network operator, where the OTT services don't require any business or technology affiliations with the network operator. For example, televisions (TVs), Digital Video Disk (DVD) players and video game consoles are being built with wireless connectivity such that they can “piggyback” on an existing wireless network and pull content from the Internet. OTT services are likely to have a significant role in the proliferation of Internet television and Internet-connected TVs. OTT services may include audio, video, data, voice and other services.

The Internet Protocol (IP) multimedia subsystem (IMS), defined by the 3rdGeneration Partnership Project (3GPP), is an architectural framework for implementing IP-based telephony and multimedia services. IMS defines a set of specifications that enables the convergence of voice, video, data and mobile technology over an all IP-based network infrastructure. In particular, the IMS fills the gap between the two most successful communication paradigms—cellular and Internet technology, by providing Internet services everywhere using cellular technology in a more efficient way. Session Initiation Protocol (SIP) is the main protocol for the IMS. SIP is an application layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Various OTT communications products exist in the marketplace. One problem OTT communications products encounter when executing within a mobile device environment is that they are normally treated as just another app, such as a web browser. As such, OTT communications products are often subject to interruptions by the operating system for tasks that the operating system treats as having a higher priority. For example, an ongoing OTT call (e.g., a Voice over Internet Protocol (VoIP) OTT call) being received by an OTT app at a mobile device will be interrupted by an incoming call to the mobile device's Mobile Directory Number, and in many cases the OTT call is immediately disconnected due to the operating system reassigning the shared device resources (e.g., microphone, speaker, touch screen interface) to the MDN call. From the mobile user's perspective, this loss of the OTT call is highly undesirable since the OTT call may be considered by the user to be as important, or more important, than the MDN call.

To remedy this OTT call and MDN call conflict problem within mobile devices, mobile providers have opened up access for OTT calling applications to register their calls with the operating system such that OTT calls have a same priority as MDN calls. However, in existing mobile devices, the operating system call manager typically limits concurrent calls to two calls, such as one OTT call and one MDN call. OTT calling applications, though, can be capable of supporting more than two concurrent OTT calls, creating problems between the OTT calling application and the operating system call manager which only supports two concurrent calls.

Exemplary embodiments described herein deploy a delegation model to resolve the problem of the operating system call manager only supporting two concurrent calls. In the delegation model, the OTT calling application reports only a single OTT call to the operating system call manager and internally manages any number of OTT calls greater than the single OTT call. The OTT calling application manages which of the multiple OTT calls is active, and puts the inactive OTT call(s) on-hold. In this delegation model, mobile device users use the operating system's user interface to swap between OTT calls and MDN calls, and the OTT calling application's user interface to swap between multiple OTT calls.

FIG. 1illustrates an exemplary network environment100in which multiple OTT calls to a mobile device, and calls to a mobile directory number (MDN) of the mobile device, are managed. Network environment100may include a signaling network105, a mobile network110, a transport network115, a called mobile device120, multiple calling mobile devices125-1through125-m(where m is greater than or equal to one), and multiple calling OTT devices130-1through130-x(where x is greater than or equal to one).

Signaling network105may include, for example, an IMS network that may use SIP for voice and multimedia session control. Signaling network105may connect to an OTT telephony application server (TAS)135and a mobile network (MN) TAS140. OTT TAS135may include one or more network devices that perform functions related to OTT communication sessions. For example, OTT TAS135may control the activation or inactivation of OTT calls, including suspending the transport of OTT calls through transport network115, and resuming the transport of OTT calls through transport network115. MN TAS140may include one or more network devices that perform functions related to communication sessions through mobile network110. Signaling network105may include additional signaling components, not shown inFIG. 1, as described with respect toFIG. 2below.

Mobile network110may include a wireless Public Land Mobile Network (PLMN) or a satellite network. The wireless PLMN may include a Code Division Multiple Access (CDMA) 2000 PLMN, a Global System for Mobile Communications (GSM) PLMN, a Long Term Evolution (LTE) PLMN and/or other types of PLMNs. Mobile network110may wirelessly connect to called mobile device120and calling mobile devices125-1through125-m. Mobile network110may additionally connect to signaling network105and transport network115via wired or wireless links.

Transport network115may include one or more networks of any type that transport OTT calls from a source OTT calling app to a destination OTT calling app. Transport network115may include, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cable network, a Public Switched Telephone Network (PSTN), an intranet, and/or the Internet. Transport network115may implement circuit-switched or packet-switched telephony. The packet-switched telephony may include Internet Protocol (IP) based telephony (e.g., VoIP). As shown, transport network115may include at least one OTT transport server145. OTT transport server145may route OTT call traffic from an OTT call source (e.g., calling mobile device125) to an OTT call destination (e.g., called mobile device120).

Called mobile device120may include any type of electronic device that may send/receive OTT calls and send/receive mobile network calls from/to a mobile directory number (MDN) associated with mobile device120within mobile network110. Called mobile device120may include, for example, a telephone (land-line or mobile), a personal digital assistant (PDA), a vehicular communication system, or a computer (e.g., tablet, palmtop, or laptop). In one embodiment, called mobile device120may include a “smart” mobile phone. Called mobile device120further has an Operating System (OS) call manager150and an OTT calling app155. OS call manager150includes executable OS software that may manage MDN calls and an OTT call received at called mobile device120. OTT calling app155may include executable app software that manages multiple OTT calls received at called mobile device120in a manner that is transparent to OS call manager150. In one exemplary implementation, OS call manager150may include Apple's “Call Kit,” or a similar OS application. In another exemplary implementation, OTT calling app155may include Verizon's “OneTalk” OTT calling app, or a similar OTT calling app.

Calling mobile devices125-1through125-mmay each include any type of electronic device that may send/receive OTT calls via mobile network110and transport network115, and may send/receive mobile network calls from/to a mobile directory number (MDN) associated with mobile device120or mobile devices125within mobile network110. Calling mobile devices125may each include, for example, a telephone (land-line or mobile), a personal digital assistant (PDA), or a computer (e.g., tablet, desktop, palmtop, or laptop). In one embodiment, some of calling mobile devices125may include a “smart” mobile phone.

Calling OTT devices130-1through130-xmay each include any type of electronic device that that may send/receive OTT calls via transport network115. Calling OTT devices130may connect to transport network115via wired or wireless links (e.g., Wi-Fi links). As shown, each of calling OTT devices130further has an OTT calling app155for use in sending or receiving an OTT call via transport network115.

The configuration of network components of network environment100shown inFIG. 1is for illustrative purposes. Other configurations may be implemented. Therefore, network environment100may include additional, fewer and/or different components that may be configured in a different arrangement than that depicted inFIG. 1.

FIG. 2is a diagram that depicts an overview of the use of SIP signaling for controlling the transmission of OTT traffic associated with an OTT call session between calling device125/130and called mobile device120.FIG. 2further depicts exemplary components of signaling network105that may used for SIP signaling associated with the OTT call session.

As shown inFIG. 2, signaling network105may include a Proxy Call Session Control Function (P-CSCF)205-P1, a serving CSCF (S-CSCF)205-S1, an Interrogating CSCF (I-CSCF)205-I, a S-CSCF205-S2, and a P-CSCF205-P2. P-CSCF205-P1, S-CSCF205-S1, I-CSCF205-I, S-CSCF205-S2, and P-CSCF205-P2may be generically and individually referred to herein as “CSCF205”. P-CSCF205-P1acts as an edge of the IMS network through which calling mobile devices125/130and called mobile device120obtain access. P-CSCF205-P1maintains an awareness of all IMS endpoints (including devices120,125and130) that are currently registered with the IMS network, and performs various manipulations of SIP signaling messages that are arriving from, or being sent to, the IMS endpoints that are registered with S-CSCF205-S1. P-CSCF205-P1maintains a connection with S-CSCF205-S1for called mobile device120.

S-CSCF205-S1processes all originating and terminating SIP requests and responses associated with endpoints registered with S-CSCF205-S1(including called mobile device120-1). S-CSCF205-S1routes the SIP signaling towards its destination (e.g., towards called mobile device120via P-CSCF205-P1, towards I-CSCF205for destination device125/130, or towards OTT transport server145). S-CSCF205may route the SIP signaling request to the application server (e.g., OTT TAS135or MN TAS140) for further processing.

I-CSCF205-I passes SIP signaling to/from S-CSCF205-S1and S-CSCF205-S2. I-CSCF205-I queries a Home Subscriber Server (HSS) (not shown) using diameter signaling to learn the identity of the S-CSCF assigned to a given device (e.g., called mobile device120) so that it can properly forward the SIP signaling.

S-CSCF205-S2processes all originating and terminating SIP requests and responses associated with endpoints registered with S-CSCF205-S2(including device125/130). S-CSCF205-S2routes the SIP signaling towards its destination (e.g., towards device125/130via P-CSCF205-P2or towards called mobile device120via I-CSCF205-I or S-CSCF

P-CSCF205-P2acts as an edge of the IMS network through which device125/130obtains access. P-CSCF205-P2maintains an awareness of all IMS endpoints (including device125/130) that are currently registered with the IMS network, and performs various manipulations of SIP signaling messages that are arriving from, or being sent to, the IMS endpoints (e.g., device125/130) that are registered with S-CSCF205-S2. P-CSCF205-P2maintains a connection with S-CSCF205-S2for device125/130.

As shown inFIG. 2, OTT TAS135may engage in SIP signaling via signaling network105, including sending SIP signaling to S-CSCF205-S1, which forwards the signaling to OTT transport server145for sending instructions regarding transport of OTT traffic between device125/130and mobile device120. Additionally,FIG. 2depicts OTT transport server145engaging in SIP signaling, via signaling network105, to send notifications to OTT TAS135. The notifications may include, for example, notifications related to an OTT session between device125/130and mobile device120.FIG. 2further depicts OTT traffic, associated with one or more OTT sessions, sent from device125/130to mobile device120, and from mobile device120to device125/130, with OTT transport server145acting as a transport router. OTT traffic, from device125/130may be routed by OTT transport server145to reach its destination called mobile device120across transport network115. Signaling network105, therefore, serves as the signaling medium for establishing, suspending, resuming and terminating OTT sessions between device125/130and mobile device120, and transport network115serves as the transport medium for transporting OTT traffic between device125/130and mobile device120, with OTT transport server145serving as the transport router for routing OTT traffic from a source to a destination.

The configuration of network components of signaling network105and transport network115shown inFIG. 2is for illustrative purposes. Other configurations may be implemented. Therefore, signaling network105and/or transport network115may include additional, fewer and/or different components that may be configured in a different arrangement than that depicted inFIG. 2.

FIG. 3is a diagram that depicts exemplary components of a device300. Mobile devices120and125, OTT devices130, OTT TAS135, MN TAS140, OTT transport server145, and CSCF205may each be similarly configured to device300. Device300may include a bus310, a processing unit320, a main memory330, a read only memory (ROM)340, a storage device350, an input device360, an output device370, and a communication interface380. Bus310may include a path that permits communication among the components of device300.

Processing unit320may include one or more processors or microprocessors, or processing logic, which may interpret and execute instructions. Main memory330may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing unit320. ROM340may include a ROM device or another type of static storage device that may store static information and instructions for use by processing unit320. Storage device350may include a magnetic and/or optical recording medium. Main memory330, ROM340and storage device350may each be referred to herein as a “tangible non-transitory computer-readable medium.” The process/methods set forth herein can be implemented as instructions that are stored in main memory330, ROM340and/or storage device350for execution by processing unit320. For example, OS call manager150and/or OTT calling app155may be implemented as instructions that are stored in main memory330, ROM340and/or storage device350for execution by processing unit320.

The software instructions may be read into memory330from another computer-readable medium, such as storage device350, or from another device via communication interface380. The software instructions contained in main memory330may cause processing unit320to perform operations or processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, exemplary implementations are not limited to any specific combination of hardware circuitry and software.

Input device360may include one or more mechanisms that permit an operator to input information to device300, such as, for example, a keypad or a keyboard, a display with a touch sensitive panel, voice recognition and/or biometric mechanisms, etc. Output device370may include one or more mechanisms that output information to the operator, including a display, a speaker, etc. Input device360and output device370may, in some implementations, be implemented as a user interface (UI) that displays UI information and which receives user input via the UI (e.g., a graphical touch screen user interface). Communication interface380may include one or more transceivers that enable device300to communicate with other devices and/or systems. For example, communication interface380may include wired and/or wireless transceivers for communicating via signaling network105, mobile network110, and/or transport network115.

The configuration of components of device300illustrated inFIG. 3is for illustrative purposes. Other configurations may be implemented. Therefore, device300may include additional, fewer and/or different components than those depicted inFIG. 3.

FIGS. 4A-4Care flow diagrams illustrating an exemplary process for managing multiple incoming OTT calls at a called mobile device120. The exemplary process ofFIGS. 4A-4Cmay be performed by processing unit320(e.g., executing OS call manager150and OTT calling app155) and communication interface380of called mobile device120in conjunction with OTT TAS135. The exemplary process ofFIGS. 4A-4Cis described herein with reference to the messaging diagrams ofFIGS. 5A-5C.

The exemplary process may include OTT calling app155at called mobile device120receiving a push notification for a first OTT call from OTT TAS135(block400). A calling mobile device125or calling OTT device130may initiate an OTT call, via an OTT calling app155, to called mobile device120. OTT TAS135may receive a call request associated with the OTT call, and send a push notification for the OTT call to OTT calling app155at called mobile device120. OTT TAS135may send the push notification for the OTT call via, for example, signaling network105, and mobile network110, for receipt at called mobile device120.FIG. 5Adepicts OTT TAS135sending a push notification500to OTT calling app155at mobile device120to notify device120of an incoming OTT call. OTT calling app155at called mobile device120, upon receipt of the push notification, notifies OS call manager150of the OTT call (block403). As shown inFIG. 5A, OTT calling app155sends an internal notification503to OS call manager150to notify OS call manager150of the incoming OTT call. OS call manager150registers the first OTT call (block405) and displays the first OTT call via the OS user interface (block407). OS call manager150, within its call status management functionality, registers the new OTT call, and designates it as an active call. Additionally, OS call manager150inactivates (e.g., places on hold) any currently active MDN call when the user accepts the incoming OTT call. To inactivate a MDN call, OS call manager150may send a message to MN TAS140requesting the MDN call to be inactivated.FIG. 5Adepicts OS call manager150registering505the OTT call, and displaying508the OTT call via the OS user interface.

OS call manager150determines if the user of called mobile device120accepts the OTT call (block410). Various techniques may be used by the user at mobile device120to accept the OTT call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device120, shaking mobile device120to cause the OTT call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device120to cause the OTT call to be answered. Other techniques or inputs may be used for determining if the user of mobile device120accepts the incoming OTT call. If the user does not accept the OTT call (NO—block410), then OS call manager150maintains the current call status of any MDN call(s) (block413). If there is currently an active (i.e., ongoing) and/or inactive (e.g., on-hold) MDN call(s), then OS call manager150maintains the active or inactive status of the MDN call(s). If, however, the user accepts the incoming OTT call (YES—block415), then OS call manager150designates the OTT call status as active, inactivates any active MDN call, and indicates the OTT call as an active call via the OS user interface (block415).FIG. 6depicts an example of the OS user interface600of mobile device120where a touch screen is a component of OS user interface600. As shown, the OTT call is represented by a highlighted icon605that includes a descriptor (e.g., phone number) for the OTT call and a visual indication that the call is active (e.g., a bright color), and the MDN call is represented by an icon610that includes a descriptor for the MDN call and a visual indication that the call is inactive (e.g., darkened color). Referring back toFIG. 5A, OS call manager150determines510if the call is accepted, and if accepted, OS call manager150designates513the OTT call status as active, inactivates any MDN call, and indicates the OTT call as active via the OS user interface.

OS call manager150assigns shared device resources to the OTT call (block418). The shared device resources of mobile device120may include the speaker(s), microphone(s), camera(s), and/or touch screen display of mobile device120. The shared device resources of mobile device120may additionally other resources (e.g., communication interface) not described above. Assignment of the shared device resources to the OTT call may, for example, preclude any MDN call from using the assigned shared device resources.FIG. 5Adepicts OS call manager150assigning515the shared device resources to the OTT call. OTT calling app155identifies the OTT call status as active via the OTT calling app user interface (block420). As shown inFIG. 7A, the OTT call is represented by a highlighted icon710, within OTT calling app user interface700, that includes a descriptor for the OTT call and a visual indication that the call is active (e.g., a highlighted or bright color). OTT calling app user interface700includes a separate user interface, from the OS user interface, that maintains indications of call status for OTT calls, but may not maintain indications of status for MDN calls that are managed by OS call manager150. Referring back toFIG. 5A, OTT calling app155is shown identifying517the OTT call status as active via the OTT calling app user interface.

Referring toFIG. 4B, OTT calling app155at called mobile device120receives a push notification for an nth OTT call, where n is greater than or equal to two (block423). In the first iteration of blocks423through460, subsequent to the first OTT call, the nth OTT call would be the second OTT call. Blocks423through460ofFIGS. 4B and 4C, however, may be executed in parallel for every subsequent nth OTT call received at called mobile device120. The nth OTT call, therefore, may include the second OTT call, the third OTT call, the fourth OTT call, etc.FIG. 5Bdepicts a push notification518being sent from OTT TAS135to OTT calling app155at mobile device120. OTT calling app155at called mobile device120presents the nth OTT call to the user via the OTT calling app user interface (block425).FIG. 7Bdepicts the nth OTT call being presented as a highlighted icon720within OTT calling app user interface700, where highlighted icon720includes a descriptor for the nth OTT call (e.g., an originating telephone number) and a visual indication that the call is awaiting acceptance (e.g., bright red).FIG. 5Bdepicts OTT calling app155presenting520the nth OTT call to the user via the OTT calling app user interface.

OTT calling app155at called mobile device120determines if the user accepts the nth call (block428). Various techniques may be used by the user at mobile device120to accept the nth OTT call including, for example, touching the highlighted icon720, shown inFIG. 7B. Other techniques or inputs, however, may alternatively be used for determining if the user of mobile device120accepts the incoming nth OTT call. If the user does not accept the nth OTT call (NO—block428), then OTT calling app155maintains the current call status of active and inactive OTT calls (block430). If the user accepts the nth call (YES—block428), then OTT calling app155sends a request to OTT TAS135to switch from the current active OTT call to the nth OTT call (block433).FIG. 5Bdepicts OTT calling app155determining523if the user accepts the nth OTT call, and sending a request message525to OTT TAS135requesting OTT TAS135to switch from the current active OTT call to the nth OTT call.

Upon receipt of the request from OTT calling app155, OTT TAS135signals the suspension of the transport of the current OTT call and starting transport of the nth OTT call to the called mobile device120(block435). OTT TAS135may, for example, signal, via signaling network105and transport network115, OTT transport server145to suspend transport of the current OTT call and to begin transporting the nth OTT call to mobile device120.FIG. 5Bdepicts OTT TAS135engaging in signaling528the suspension of transport of the currently active OTT call, and starting the transport of the nth OTT call to mobile device120.

OTT calling app155designates an inactive call status for the previous OTT call, and an active call status for the nth OTT call (block438). As shown inFIG. 7C, icon710for the 1st OTT call may be changed, for example, to a darkened, inactive state, and icon720for the nth OTT call may be changed, for example, to a highlighted state. The highlighted state may include, for example, a blinking icon720, icon720having a color that stands out from other objects displayed in the OTT calling app user interface or the OS user interface, or icon720scrolling, rotating, or providing some other indication within the user interface that the first OTT call has changed to an inactive call status.FIG. 5Bdepicts OTT calling app155designating530an inactive call status for the previous OTT call and an active call status for the nth OTT call. OTT calling app155allocates the shared device resources, assigned by the OS call manager150, to the nth OTT call (block440). OS call manager150previously assigned the shared device resources to the active OTT call. OTT calling app155merely transfers this assignment to the nth OTT call to allocate the shared device resources.FIG. 5Bdepicts OTT calling app155allocating531the shared device resources, previously assigned by the OS call manager to the previous OTT call, to the nth OTT call.

Referring toFIG. 4C, OTT calling app155determines if the nth OTT call is to be terminated (block443). For example, the nth call may be terminated by the receipt of signaling that the OTT call has been terminated on the calling end. Alternatively, the nth call may be terminated by the user of called mobile device120providing an indication that the call is being terminated. For example, the user of mobile device120may touch the “end call” button upon the OTT calling app user interface.FIG. 5Cdepicts OTT calling app155at called mobile device120determining whether the nth OTT call is to be terminated. If the nth OTT call is not to be terminated (NO—block443), then block443may repeat continuously until the OTT call is terminated. If the nth OTT call is to be terminated (YES—block443), then OTT calling app155may determine if there is currently a single OTT call that is active or inactive (block445). The processing/messaging associated with a determination that there is only a single OTT call that is active/inactive is depicted at537inFIG. 5C. The processing/messaging associated with a determination that there is more than a single OTT call that is active/inactive is depicted at539inFIG. 5C.

If there is only a single OTT call active or inactive (YES—block445), then OTT calling app155sends a message to OTT TAS135indicating the termination of the nth OTT call (block448). OTT calling app155may send a message to OTT TAS135via mobile network110and signaling network105.FIG. 5Cdepicts OTT calling app155sending a notification message540that notifies OTT TAS135of the termination of the nth OTT call. OTT calling app155notifies OS call manager150of the OTT call termination (block450), and OS call manager150removes the OTT call from the OS user interface based on receipt of the notification from OTT calling app155(block455).FIG. 5Cdepicts OTT calling app155sending a notification545to OS call manager150indicating the OTT call termination, and OS call manager150, upon receipt of the notification545, removing550the OTT call from the OS user interface. OTT calling app155designates the nth OTT call status as “terminated” and removes the nth OTT call from the OTT calling app155′s user interface (block460). Referring back toFIG. 7C, OTT calling app155may remove icon720from OTT calling app user interface700.FIG. 5Cdepicts OTT calling app155designating555the nth OTT call status as terminated and removing557the nth OTT call from the OTT calling app user interface.

Referring toFIG. 4C, if there is more than a single OTT call that is active or inactive (NO—block445), then OTT calling app155sends a message to OTT TAS135indicating the termination of the nth OTT call (block465). OTT calling app155may send a message to OTT TAS135via mobile network110and signaling network105.FIG. 5Cdepicts OTT calling app535sending a notification message560that notifies OTT TAS135of the termination of the nth OTT call.

OTT calling app155designates the nth OTT call status as “terminated” and removes the nth OTT call from the OTT calling app155′s user interface (block470). Referring again toFIG. 7C, OTT calling app155may remove icon720from OTT calling app user interface700.FIG. 5Cdepicts OTT calling app155designating565the nth OTT call status as terminated and removing470the nth OTT call from the OTT calling app user interface.

FIG. 8is a flow diagram illustrating an exemplary process for switching from an MDN call at called mobile device120to an OTT call of n inactive OTT calls. The exemplary process ofFIG. 8may be performed by processing unit320(e.g., executing OS call manager150and OTT calling app155) and communication interface(s)380of called mobile device120in conjunction with OTT TAS135. The exemplary process ofFIG. 8is described herein with reference to the messaging diagrams ofFIG. 9. Prior to the start of the exemplary process ofFIG. 8, an MDN call is active and n OTT calls are inactive, where n is greater than or equal to two. For example, a user of called mobile device120is engaged in a MDN call, and n OTT calls are on-hold.

The exemplary process may include OS call manager150displaying the active MDN call and an inactive OTT call in the OS user interface (block800). For example, instead of the call statuses shown inFIG. 6, icon610may be highlighted as an active call, and icon605may be de-highlighted (e.g., darkened) as an inactive call.FIG. 9depicts OS call manager150of called mobile device120displaying900a MDN call and OTT call in the OS user interface.

OTT calling app155displays n inactive OTT calls in the OTT calling app user interface, where n is greater than or equal to two (block805). For example, instead of the display shown inFIG. 7B, icons710and720of OTT calling app user interface700may be de-highlighted (e.g., darkened) to indicate that the calls are inactive.FIG. 9depicts OTT calling app155displaying905the n inactive OTT calls in the OTT calling app user interface. OTT calling app155determines if the user of mobile device120selects an OTT call of then inactive OTT calls (block810). Various techniques may be used by the user at mobile device120to select an OTT call of the n inactive calls including, for example, the user touching an icon710or720of OTT calling app user interface700, shown inFIG. 7B. Other techniques or inputs, however, may alternatively be used for determining if the user of mobile device120selects an OTT call of then inactive calls. If the user does not select an OTT call (NO—block810), the exemplary process returns to block800. If OTT calling app155determines that the user has selected an OTT call of the n inactive OTT calls (YES—block810), then OTT calling app155notifies the OS call manager150of a switch to the OTT call from the active MDN call (block815).FIG. 9depicts user selection910of an OTT call of then inactive OTT calls, and OTT calling app155, based on the user selection, sending a notification915to OS call manager150that indicates a switch from the MDN call to the selected OTT call.

OS call manager150inactivates the MDN call (block820) and displays the OTT call in the OS user interface as the active call (block825). For example, instead of the call statuses shown inFIG. 6, icon610may be de-highlighted (e.g., darkened) as an inactive call, and icon605may be highlighted as an active call.FIG. 9depicts OS call manager150inactivating920the MDN call, and displaying925the OTT call in the OS user interface as the active call.

OS call manager150assigns shared device resources to the OTT call (block830). The shared device resources of mobile device120may include the speaker(s), microphone(s), camera(s), and/or touch screen display of mobile device120. The shared device resources of mobile device120may additionally other resources (e.g., communication interface) not described above. Assignment of the shared device resources to the OTT call may, for example, preclude any MDN call from using the assigned shared device resources.FIG. 9depicts OS call manager150assigning930the shared device resources of mobile device120to the OTT call.

OTT calling app155sends a request to OTT TAS135to activate the selected OTT call of the n OTT calls that are currently inactive (block835). Upon receipt of the request to activate the selected OTT call, OTT TAS135may, for example, signal, via signaling network105and transport network115, OTT transport server145to resume transport of the selected OTT call to mobile device120. OTT transport server145, upon receipt of the signaling from OTT TAS135, resumes the inactivated (e.g., on-hold) OTT call by transmitting OTT traffic associated with the OTT call between device125/130and mobile device120.FIG. 9depicts OTT calling app155sending a request935that requests that the user selected OTT call of the n inactive OTT calls be activated. OTT calling app155indicates the selected OTT call as the active call in the OTT calling app user interface (block840). For example, instead of the call statuses shown inFIG. 7B, icon720may be highlighted as an active call, and icon720may be de-highlighted (e.g., darkened) as an inactive call.FIG. 9depicts OTT calling app155indicating940the selected OTT call as the active call in the OTT calling app user interface.

FIG. 10is a flow diagram illustrating an exemplary process for managing an incoming MDN call at called mobile device120when there are already n active or inactive OTT calls at mobile device120. The exemplary process ofFIG. 10may be performed by processing unit320(e.g., executing OS call manager150and OTT calling app155) and communication interface(s)380of called mobile device120in conjunction with OTT TAS135. The exemplary process ofFIG. 10is described herein with reference to the messaging diagram ofFIG. 11. Prior to the start of the exemplary process ofFIG. 10, n OTT calls, where n is greater than or equal to two, are already active or inactive at called mobile device120. For example, a user of called mobile device120may be engaged in an OTT call, and have at least one other OTT call on-hold, when an incoming MDN call occurs.

The exemplary process may include OS call manager150determining if the user of called mobile device120has accepted an incoming MDN call (block1000). Various techniques may be used by the user at mobile device120to accept the incoming MDN call including, for example, pressing an “answer” button upon a touch screen of the OS user interface of mobile device120, shaking mobile device120to cause the MDN call to be answered, or performing a sliding motion upon a button of the touch screen of the OS user interface of mobile device120to cause the MDN call to be answered. Other techniques or inputs may be used for determining if the user of mobile device120accepts the incoming MDN call. If the user has accepted an incoming MDN call (YES—block1000), then OS call manager150notifies OTT calling app155of the new MDN call (block1005).FIG. 11depicts a user accepting1100an incoming MDN call, and OSS call manager150, based on acceptance of the MDN call, sending a notification1110to OTT calling app155indicating the new incoming MDN call.

OS call manager150designates the OTT call status as inactive, the MDN call as active, and indicates the MDN call as the active call via the OS user interface (block1010). For example, instead of the call statuses shown inFIG. 6, icon605for the OTT call may be de-highlighted (e.g., darkened) as an inactive call, and icon605for the MDN call may be highlighted as an active call.FIG. 11depicts OS call manager150designating1105the OTT call status as inactive, the MDN call as inactive, and indicating the MDN call as the active call via the OS user interface.

OS call manager150assigns shared device resources to the MDN call (block1015). The shared device resources of mobile device120may include the speaker(s), microphone(s), camera(s), and/or touch screen display of mobile device120. The shared device resources of mobile device120may additionally other resources (e.g., communication interface) not described above. Assignment of the shared device resources to the MDN call may, for example, temporarily preclude any OTT call from using the assigned shared device resources.FIG. 11depicts OS call manager150assigning1115the shared device resources to the OTT call.

OTT calling app155sends a request to OTT TAS135to inactivate the currently active OTT call of then OTT calls (block1020).FIG. 11depicts OTT calling app155sending a request message1120that requests the inactivation of the currently active OTT call of n OTT calls. OTT TAS135signals the suspension of transport of the OTT call (block1025).

Upon receipt of the request to inactivate the currently active OTT call of the n OTT calls, OTT TAS135may, for example, signal, via signaling network105and transport network115, OTT transport server145to suspend transport of OTT traffic, associated with the currently active OTT call, to mobile device120. OTT transport server145, upon receipt of the signaling from OTT TAS135, suspends the OTT call (e.g., places on hold) by temporarily stopping the transmission of OTT traffic associated with the OTT call between device125/130and mobile device120.FIG. 11depicts OTT TAS135signaling the suspension of transport of the OTT call.

OTT calling app155sets the call status of the OTT call as inactive (block1030). For example, similar to the call status associated with icon710shown inFIG. 7B, the icon of the OTT call may be de-highlighted (e.g., darkened) as an inactive call within OTT call app user interface700.FIG. 11depicts OTT calling app155setting1125the call status of the OTT call as inactive.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while series of blocks have been described with respect toFIGS. 4A-4C, 8, and 10, and message/activity flows with respect toFIGS. 5A-5C, 9, and 11, the order of the blocks and/or message/activity flows may be varied in other implementations. Moreover, non-dependent blocks may be performed in parallel.