Cross-Process Media Handling in a Voice-Over-Internet Protocol (VOIP) Application Platform

Abstract

A computer-implemented system is provided that facilitates implementation of a voice-over-IP (VOIP) application. The system includes a host system and a user interface (UI) host process residing on the host system. The system also includes an agent host process residing on the host system which is being configured to process a VOIP call received by one or more VOIP applications executable on the host system. A moniker protocol is utilized for redirection of input and output between a media element which is utilized to render media on a display on the system. The redirection enables media processing to be allocated between the UI host process in the foreground and the agent host process in the background to thereby reduce latency perceived by a user during a VOIP experience.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. Ser. No. 13/535,502, filed Jun. 28, 2012, entitled, “CROSS-PROCESS MEDIA HANDLING IN A VOICE-OVER-INTERNET PROTOCOL (VOIP) APPLICATION PLATFORM”, now U.S. Pat. No. 9,191,417, issued Nov. 17, 2015, which is incorporated herein by reference in its entirety.

BACKGROUND

Developing voice-over-Internet protocol (VOIP) applications to run on mobile phones or other limited resource devices (e.g., tablets, personal digital assistants) presents a number of challenges. These challenges are even greater when the VOIP applications are to scale so that they are operational on low end hardware devices having limited resources as well as high end hardware devices having greater resources, particularly when the quality of the VOIP call user experience is to remain relatively high in all cases.

One peculiarity of a mobile phone as a platform for a VOIP application, as opposed to a personal computer, tablet, or the like, is that a mobile phone has a pre-existing telephony (e.g., cellular) module already built into it. Thus, when developing a VOIP application for a mobile phone, issues arise such as switching between different types of calls, which do not arise when a personal computer or tablet is used as a platform for the VOIP application. More generally, it becomes desirable to integrate the user experience of receiving and placing all types of calls, including VOIP calls and cellular or other types of calls that are native to the mobile phone.

Another problem that arises when developing a VOIP application that does not arise with other types of calls native to the mobile phone or other limited resource devices concerns the sharing of hardware resources (e.g., processing capability, memory) among various applications. If, for example, a user switches to another application while on a VOIP call, hardware resources are allocated to the other application which may negatively impact the VOIP call user experience.

SUMMARY

A system and method is provided that facilitates the development and operation of original equipment manufacturer (OEM) and third-party VOIP applications on a host system. In some embodiments a platform for running VOIP applications is provided for a mobile (e.g., cellular) phone that serves as the host system. The platform allows VOIP applications to be developed which scale with the hardware resources of the host system while preserving the quality of the VOIP call user experience on both low end and high end host systems.

In one particular implementation, the VOIP platform is partitioned into different processes in order to conserve resources and minimize the impact on battery life. One process implements UI (user interface) functions and only runs when the UI is being used and the other process implements call processing functionality and runs whenever a VOIP call is in progress. That is, a UI host process may run in the foreground while an agent host process runs in the background, when the application is not displaying any UI. Thus, all of the code in the VOIP application that needs to run in the background will run in the agent host process and all code related to the UI of the VOIP application will run in the UI host process.

In yet another particular implementation, in order to further conserve resources and battery life a push client service that is pre-existing on the host system may be used to notify the agent host process that an incoming VOIP call is being received. In addition, a keep-alive agent may be provided for ensuring that the push notification channel used by the push client service remains active, as well as for periodically communicating with the cloud service associated with the VOIP application.

In an illustrative embodiment of a VOIP application, cross-process media handling is realized in which a moniker protocol operates in a foreground application to indicate instances when an input into a media element (i.e., a media player object) comes from a cross-process source. The foreground application is configured to own the responsibility for compositing a foreground application scene using the media element as a placeholder for the rendered output as part of a foreground process (e.g., as a UI host process). However, the bulk of the processing can be performed as a background process (e.g., an agent host process) and the application may be arranged to choose between in-process or cross-process elements so the latency between media transport and presentation is reduced. Advantageously, the cross-process media handling enables the video aspects to be optionally utilized or delayed in order to support an enhanced VOIP call experience to the user.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates one example of the various tasks and processes associated with a VOIP application platform running on a host system.

FIG. 2 shows the architecture of one example of a host system on which one or more VOIP applications may be executed.

FIG. 3 is a system diagram depicting an exemplary mobile device 300 including a variety of optional hardware and software components, shown generally at 302.

FIG. 4 is a flowchart showing one example of a method for enabling operation of one or more VOIP applications on a host system.

FIG. 5 shows an illustrative software architecture which may facilitate practice of an embodiment of cross-process media handling.

FIG. 6 shows illustrative functionalities implemented using various processes.

FIG. 7 shows an illustrative example in which three processes are used to handle media transport and presentation functionality.

FIG. 8 shows an illustrative dummy moniker that indicates an in-process or cross-process as input to a media element.

FIG. 9 is an illustrative flowchart that depicts the interaction between various elements and processes.

DETAILED DESCRIPTION

Overview

Simplified overviews are provided in the present section to help enable a basic or general understanding of various aspects of exemplary, non-limiting embodiments that follow in the more detailed description and the accompanying drawings. This overview section is not intended, however, to be considered extensive or exhaustive. Instead, the sole purpose of the following embodiment overviews is to present some concepts related to some exemplary non-limiting embodiments of the disclosed subject matter in a simplified form as a prelude to the more detailed description of these and various other embodiments of the disclosed subject matter that follow. It is understood that various modifications may be made by one skilled in the relevant art without departing from the scope of the disclosed subject matter. Accordingly, it is the intent to include within the scope of the disclosed subject matter those modifications, substitutions, and variations as may come to those skilled in the art based on the teachings herein.

As used in this application, the term “host” generally refers to a computer or a computer-related entity at a specific location on a computer network. Typically, a host can comprise a storage component (e.g., volatile and non-volatile storage and associated software for storage and/or execution of data and/or instructions), a host central processing unit (CPU) (e.g., for controlling the functions of the host according to data and/or instructions), and a communications component (e.g., one or more network devices and associated software for communication with other network components). In addition, a location on a network can be described by an IP address. Thus, in addition to including such computer-related entities as desktop computers, laptop computers, server computers, network attached appliances with computing capability, and so on, the term host can include, for example, a tablet personal computer (PC) device, a Smartphone, and/or a personal digital assistant (PDA), and so on.

Furthermore, as used in this application, the terms “component,” “process.” “module,” “system,” and the like generally refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, software in execution, firmware, middle ware, microcode, and/or any combination thereof. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, not limitation, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal). Additionally, components of systems described herein may be rearranged and/or complemented by additional components in order to facilitate achieving the various aspects, goals, advantages, etc., described with regard thereto, and are not limited to the precise configurations set forth in a given figure, as will be appreciated by one skilled in the art.

Additional terminology as used herein is as follows.

Application

An “application” is a unit of installation and not a run-time entity. It consists of a set of binaries and files installed onto the phone. An application is a security principal and, at run-time, all binaries of an application are loaded only in processes that are running in the security context of the application.

Task

A “task” is logical unit of functionality in the application model. All applications (both first and third-party) are made up of one or more tasks. A task can be thought of as an entry point into an application.

Task Instance

A “task instance” is a task that is being executed. A task instance is a run-time entity. Task instance is to task, as process is to executable file. A task instance can be thought of as a unit of work being done by the application code at run time.

Host

A “host” is a process that contains one or more task instances of a single application. All host processes for an application run under the security context of the application.

UI Task

A “UI task” is a task that is capable of displaying UI.

Agent

An “agent” is a task that is not capable of displaying UI.

UI Host Process

A “UI host process” is a host process that only contains task instances that display UI.

Agent Host Process

An “agent host process” is a host process that can only contain background agents. An agent host process may also be referred to as a headless host process.

VOIP

“VOIP” is an acronym for Voice over Internet Protocol. As used herein, a VOIP application is an application that enables either voice-only or voice and video and/or text or other data over the internet.

VOIP Application Platform

FIG. 1 illustrates one example of the various tasks and processes associated with a VOIP application platform running on a host system. In this example the host system is a mobile phone that includes such well-known components as a media foundation and an execution model. The VOIP application 160 includes a UI host process 140 and an agent host process 150.

In those implementations in which the host system is a mobile phone, a number of components and services are already available which may be used by the VOIP application platform. These components and services are used to facilitate the provision of cellular phone service and may be extended to additionally facilitate the provision of VOIP services. Three such components and services are shown in FIG. 1.

One service made available by the host system is a phone service 110, which serves as the authority on the state of all calls currently existing on the phone (starting, ending, on hold, ringing, etc.). It provides the functionality needed to switch between calls and to handle multiple calls at the same time. The phone service 110 also sends out notifications about call states to other interested first party components of the system. It provides application programming interfaces (APIs) to display the incoming call dialog and to control audio routing for calls, which specify, for example, whether the audio is to be captured or played back from a Bluetooth headset or whether the phone speaker is to be used for call audio output. In addition, the phone service 110, in conjunction with the UI shell 202 (discussed below), is responsible for the display of a minimized call UI when the primary call UI is not in the foreground.

Another set of services and components made available by the host system is the media foundation 120. The media foundation, which may include hardware and software components, exposes one or more APIs that can be called by the VOIP application to interact with audio, video, or other media. For example, the media foundation 120 may be thought of as existing at an “infrastructure” level of software that is executed on the host system. In other words, the media foundation 120 is a software layer used by the VOIP application to interact with the media. The media foundation 120 may be utilized to control a number of aspects of the media, such as output, rendering, storage, and so on. Thus, the media foundation 120 may be utilized such that each application does not have to implement separate code for each type of media that may be used in the system. In this way, the media foundation provides a set of reusable software components to do media specific tasks.

In particular, the media foundation 120 primarily provides the audio and video capture and playback APIs for use by the active call agent instance. In FIG. 1 the media foundation 120 includes a video playback component 122, a video capture component 124, an audio capture component 126, and an audio playback component 128, which respectively communicate with the display surface 130, camera 132, microphone 134, and speaker 136 of the host system. Its video playback pipeline allows the agent host process 150 to output a raw or hardware decoded H.264 incoming video stream directly to a surface created by the UI host process 140, with the minimum number of buffer copies. In this way, displaying video that is being rendered by the agent host process 150 will be as efficient as rendering it from the UI host process 140.

The execution model 170 is another pre-existing component of the host system which can be used to provide APIs to launch and control instances of the various types of VOIP agents described herein. A subcomponent of the execution model 170, referred to as the resource manager, may also be responsible for the management and allocation of resources (e.g., CPU, memory, access to devices, etc.) used by the UI and agent host processes of the VOIP applications. The execution model 170 can multiplex the resource utilization by various applications running on the host system so as to optimize the overall resource utilization. For example, the execution model 170 can reallocate resources used by instances of a background audio playback agent to an active call agent instance 158 since there is no need to play music when a phone call is in progress. The execution model 170 may also provide scheduling logic to initiate background activity in a battery-friendly manner. For instance, keep-alive agent 152 instances may be scheduled together with generic background agents in order to minimize the amount of time the network radios are active.

With continuing reference to FIG. 1, execution of the VOIP application platform 160 is divided into two primary processes, a UI host process 140 and an agent host process 150. The UI host process 140 runs in the foreground while the agent host process 150 runs in the background, when the application is not displaying any UI. Thus, all of the code in the VOIP application that needs to run in the background will run in the agent host process 150 and all code related to the UI of the VOIP application will run in the UI host process 140. Generally, the background process is always running to ensure that there are no dropped calls.

Background, or headless, execution of VOIP application code is employed for several reasons. First, as discussed below, background execution allows keep-alive messages to be periodically sent to the appropriate VOIP server. Background notification also allows incoming call notifications to be processed. While processing incoming call notifications, the application that is currently in the foreground is not interrupted. The VOIP application may display the UI only if the user accepts the incoming call. If the user declines the call, the current foreground application continues without interruption. Background execution is also employed to process a VOIP call that is in progress when the VOIP application UI is not in the foreground. This scenario can occur either when the user accepts an incoming VOIP call and the screen is locked (i.e., a state in which at least some normally user-accessible functions of the device are not user-accessible), or when the user navigates away from the VOIP application UI in the middle of a VOIP call.

The partitioning of the VOIP application platform 160 into two primary processes is advantageous for a number of reasons. In particular, this arrangement facilitates the implementation of VOIP applications on lower end, resource limited devices because each process can run only when necessary, thereby avoiding the need to have one large process consuming resources at all times. For instance, the UI host process 140 will generally consume substantially more resources than the agent host process 150 in order to handle UI functions such as the rendering of surfaces, buttons, and the like as well as the rendering of video. The UI host process 140 is only executed when in the foreground since otherwise it is not being utilized. For instance, when the user switches away (e.g., places on hold) from a VOIP call that is in progress to accept a cellular call or access another application for instance, the UI host process 140 may be terminated. The agent host process 150, on the other hand, is generally a much smaller process that consumes fewer resources than the UI host process 140. The agent host process 150 is not terminated even if the UI host process 140 is terminated. Moreover, in some cases the foreground process may sponsor memory to the background process, thus reducing the size of the background process unless necessary.

The agent host process 150 runs whenever the VOIP application is to operate in the background. That is, the agent host process 150 runs whenever any agent instance is running in it. In particular, the agent host process 150 runs for the duration of a VOIP call as well as generally whenever the UI host process 140 is running in the foreground. Among other things, code runs in the agent host process 150 which is responsible for communicating with the VOIP service 180. All communication with the VOIP service 180 occurs from the agent host process 150, even when the UI host process 140 is in the foreground. The agent host process 150 also captures video from the camera 132 (if available in the platform) and renders it directly into the camera's preview surface, which is created by the UI host process 140. Likewise, the agent host process 150 also decodes incoming video and renders it directly into an incoming video surface created by the UI host process 140. The agent host process 140 also captures and encodes outgoing audio from the pertinent audio input device and receives, decodes, and plays back incoming audio to the pertinent audio output device. It should be noted that there is no audio or video data being transferred between the UI host process 140 and the agent host process 150.

As shown in FIG. 1, the agent host process 150 includes a keep-alive agent 152, an incoming call agent 154, a communication agent 156, and an active call agent 158. The agents essentially serve as an entry point that is invoked by the execution model to perform different types of work. Each of these agents will be described in turn.

The purpose of the keep-alive agent 152 is two-fold. First, it periodically informs the VOIP cloud service 180 that this endpoint is still connected. For example, this agent can be used to renew any authorization tokens that the VOIP cloud service 180 may have issued to this particular endpoint. Second, the keep-alive agent 152 ensures that the push notification channel (discussed below) over which incoming call notifications are sent is still active. If not, it creates a new push notification channel and registers it with the background scheduling service 206 (discussed below) and with its own cloud service. In order to conserve resources and battery life, the keep-alive agent 152 is small and lightweight; it starts, performs its operation, and shuts down quickly.

The purpose of the incoming call agent 154 is to receive information about an incoming VOIP call. In response, the incoming call agent 154 requests the phone service to display the incoming call dialog box, appropriately customized with information about the incoming call.

An instance of the incoming call agent 154 is launched or otherwise started by the background scheduling service 206 when it receives a push notification on the notification channel previously registered by the VOIP application for this purpose. The incoming call agent 154 is generally small and lightweight—it is expected to start as soon as possible upon receipt of an incoming VOIP call, retrieve information about the incoming call from the incoming push notification or the VOIP cloud service, and request the phone service 110 to display the incoming call dialog box. If the incoming call agent 154 does not request the phone service to display the incoming call dialog box within a specified amount of time (e.g., 5 seconds) of being started, it may be canceled. If the user declines the call, the incoming call agent 154 is shut down by the execution model.

If the user accepts the call, the incoming call agent 154 requests the phone service 110 to start a call. The phone service 110, in turn, requests the execution model 170 to start an active call agent instance to handle the new call. The execution model 170 starts the active call agent instance in the same agent host process 150 as the incoming call agent instance. The execution model 170 then requests the incoming call agent instance to shut down. The agent host process 150 then continues to run with the active call agent instance inside it.

The incoming call agent instance briefly shares its host process with the active call agent instance that is requested, if any. This is significant because the incoming call agent instance may have state information (e.g., open sockets to its service, call routing information, etc.) that it wishes to share with the nascent active call agent instance—having both instances share the same process makes this sharing easier.

The purpose of the active call agent 158 is to perform the functionality used during a VOIP call, both when the UI of the VOIP application is in the foreground, and when it is not. In the former case, the active call agent 158 processes both video and audio information, and in the latter, it processes only audio information. An instance of this agent is started by the phone service when a VOIP call is started. A call can be started either by an incoming call agent instance (when the user accepts an incoming call) or by the communication agent instance 156 (when the user initiates an outgoing call from the VOIP application UI).

The active call agent 158 may continuously communicate with the VOIP cloud service 180 to send and receive audio-video streams and call control information. It communicates with the phone service 110 to deliver notifications about call status and to receive call control commands (for instance, commands to put the call on hold when accepting another call or commands to end the call). The active call agent 158 uses media foundation APIs to:

• 1. Capture audio from the selected audio input device
• 2. Play incoming audio out to the selected audio output device
• 3. Capture video directly from the selected camera or via the video encoding pipeline
• 4. Play video to a surface created by the UI task instance 142 either directly or via the video decoding pipeline

Video capture and playback is performed only if the UI task instance 142 of the VOIP application is in the foreground.

VOIP applications sometimes need to communicate with their affiliated cloud service to retrieve data for the UI, even when there is no VOIP call in progress. For example, the VOIP application may be requested to display a list of contacts in its UI, and would therefore need to communicate with its cloud service to retrieve this list. However, many VOIP applications are not resilient to having multiple instances of their communication libraries coexisting at runtime. Instantiating its communication library in the UI process, and then again in the agent process, would violate this constraint. To solve this problem, the communication agent 156 can be used. An instance of this agent can be launched directly by the UI task instance 142 of the VOIP application. The UI task instance 142 can then communicate with the VOIP application's cloud service via the communication agent instance, thereby avoiding the problem of having to instantiate the communication library in both the UI and the agent host processes. The communication agent instance of a VOIP application, if any, is shut down by the execution model as soon as the UI task instance 142 of the application goes out of the foreground.

The UI task instance 142 contains the UI used to initiate and control VOIP calls. The UI task instance 142 also displays incoming video and video capture previews from the camera. When a VOIP call is in progress, the UI task instance 142 communicates with the active call agent instance to deliver call control commands. It also creates two surfaces—one for the active call agent to render the incoming video stream into, and another for the camera driver to render the capture preview into.

Host System

FIG. 2 shows the architecture of one example of a host system 200 on which one or more VOIP applications may be executed. The host system includes a number of components that may provide services to the VOIP application platform, including a UI shell 202 (in the case of a mobile phone host system) and a number of service hosts, including a navigation model 203, execution model 204 and package manager 205, a background scheduling service 206, a push client service 207, a phone service 208, and a media queue 209. The background scheduling service 206, push client service 207, and the phone service 208 have been discussed above in connection with FIG. 1. The media queue 209 largely corresponds to the media foundation. OEM and/or third party application code is largely included in the UI task host 220 and the headless host 230 agents, which are built upon the VOIP platform, e.g., the aforementioned services and APIs associated therewith which are exposed by those services.

The UI task host 220 functions to render content from input that is provided to it. Managed application code 223 incorporates the UI Host process of FIG. 1 and executes within an application framework 221 such as Microsoft Silverlight®, which includes an application domain 222 such as Microsoft's common language runtime (CLR). The UI task host 220 may also include native application code 224, an execution manager client 225, and a runtime environment such as the Windows® Runtime (WinRT) Platform 226 to communicate with other processes.

The headless host 230 functions to transport and track content. Managed application code 233 incorporates the agent host process of FIG. 1 and executes within an application framework 231 such as Microsoft Silverlight®, which includes an application domain 232 such as Microsoft's common language runtime (CLR). The headless host 230 also includes native application code 234, an execution manager client 235 and a runtime environment such as the Windows® Runtime (WinRT) Platform 236 to communicate with other processes. In some implementations the headless host 230 is generally given access on a priority basis to system resources in order to preserve call quality. Resources are allocated to the processes based on the state of the phone at any given time. In other words, all processes except for those incorporated in the headless host 230 can be compromised if resources are limited.

The background scheduling service 206 (BSS) and the package manager 205 together maintain information concerning the rules that are to be applied for launching the keep-alive and incoming call agents within each VOIP application. The BSS is responsible for initiating the launch of keep-alive agent 152 after every device reboot and periodically thereafter. The BSS also operates in conjunction with the push client service 207 to launch incoming call agents. In particular, the BSS and package manager 205 provide and implement APIs to enable and disable the launching of the keep-alive and incoming call agents upon the occurrence of various events. For instance, the user may disable these agents. In addition, the launching of these agents may be disabled if the VOIP application's license is revoked or the VOIP application is uninstalled. Likewise, the launching of these agents may be enabled when the VOIP application's license is granted.

The push client service 207 is used to notify the incoming call agent that an incoming VOIP call is being received. The push client service 207 is generally pre-existing on the host system and listens for push notifications received by various applications such as e-mail applications and the like. The pre-existing service also includes a registration mechanism which allows the push client service 207 to begin running the appropriate application (e.g., the VOIP application). In this way each VOIP application running on a host system does not need to listen for its own incoming VOIP calls. Rather, a single component that implements the push client service 207 listens for all incoming VOIP calls and upon receipt dispatches them to the appropriate application. As discussed above, the keep-alive agent 152 is responsible for ensuring that the push notification channel remains active.

The navigation model 203 provides events that inform the phone service when the UI of a VOIP application enters or leaves the foreground. These notifications are used by the phone service 208 to hide or show the minimized call UI. The navigation model 203 also provides APIs to the phone service to launch the VOIP application UI.

Example Mobile Device

FIG. 3 is a system diagram depicting an exemplary mobile device 300 including a variety of optional hardware and software components, shown generally at 302. Any components 302 in the mobile device can communicate with any other component, although not all connections are shown, for ease of illustration. The mobile device can be any of a variety of computing devices (e.g., cell phone, smartphone, tablet or other handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile communications networks 304, such as a cellular or satellite network.

The illustrated mobile device 300 can include a controller or processor 310 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system “OS”) 312 can control the allocation and usage of the components 302, including power states, above-lock states, and below-lock states, and provide support for one or more application programs 314. The application programs can include common mobile computing applications (e.g., image-related applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application.

The illustrated mobile device 300 can include memory 320. Memory 320 can include non-removable memory 322 and/or removable memory 324. The non-removable memory 322 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 324 can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory storage technologies, such as “smart cards.” The memory 320 can be used for storing data and/or code for running the operating system 312 and the application programs 314. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. The memory 320 can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

The mobile device 300 can support one or more input devices 330 for responding to inputs from users and other sources. Such input devices may include a touch screen 332, microphone 334, camera 336, physical keyboard 338, trackball 340, and/or proximity sensor 342, and one or more output devices 350, such as a speaker 352 and one or more displays 354. Other possible output devices (not shown) can include piezoelectric or haptic output devices. Some devices can serve more than one input/output function. For example, touch screen 332 and display 354 can be combined into a single input/output device.

In some implementations the various input devices 330 may support natural user interface (NUI) methods. Examples of NUI methods include those relying on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence. Specific categories of NUI technologies on which Microsoft® is working include touch sensitive displays, voice and speech recognition, intention and goal understanding, motion gesture detection using depth cameras (such as stereoscopic camera systems, infrared camera systems, red-green-blue camera systems and combinations of these), motion gesture detection using accelerometers/gyroscopes, facial recognition, 3D displays, head, eye, and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface, as well as technologies for sensing brain activity using electric field sensing electrodes (EEG and related methods).

A wireless modem 360 can be coupled to an antenna (not shown) and can support two-way communications between the processor 310 and external devices, as is well understood in the art. The modem 360 is shown generically and can include a cellular modem for communicating with the mobile communication network 304 and/or other radio-based modems (e.g., Bluetooth 364 or Wi-Fi 362). The wireless modem 360 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

The mobile device can further include at least one input/output port 380, a power supply 382, a satellite navigation system receiver 384, such as a Global Positioning System (GPS) receiver, an accelerometer 386, a gyroscope (not shown), and/or a physical connector 390, which can be a USB port, IEEE 1394 (FireWire) port, and/or RS-232 port. The illustrated components 302 are not required or all-inclusive, as any components can be deleted and other components can be added.

FIG. 4 is a flowchart showing one example of a method for enabling operation of one or more VOIP applications on a host system. The method begins at block 410 where a push notification service associated with the host system listens for push notifications of incoming VOIP call received on a push notification channel. A service notification of an incoming VOIP is received at block 420 on a push notification channel. At block 430, the incoming VOIP call is dispatched to an instance of an incoming call agent employed in an agent host process residing on the host system. An instance of a UI host process is launched at block 440 to present a UI to user on a display of the host system. The UI host process will generally perform a variety of tasks, including displaying the incoming call, playing a ringtone and waiting for the user to accept or reject the call. In response to user acceptance of the VOIP call, an instance of an active call agent employed in the agent call process is launched for processing the VOIP call. The agent call process runs as either a foreground or background process for the duration of the VOIP call.

FIG. 5 shows an illustrative software architecture 500 that may be utilized in one particular illustrative embodiment which may be configured for operation on the host system 200 shown in FIG. 2 and described in the accompanying text. This embodiment facilitates cross-process media support for transport and presentation of media in various VOIP usage scenarios in which compositing of video may be performed in-process by a foreground application while the bulk of the work to decode, playback, and synchronize the video may be performed cross-process in the background. It is noted that this illustrative embodiment is described both in general terms as well as using specific terms associated with a Microsoft Silverlight application framework implementation on the previously described VOIP platform.

The architecture 500 is arranged in layers and includes a VOIP application layer 505, an OS layer 510, and a hardware layer 515. The hardware layer 515 typically provides an abstraction of the various hardware used by the host system 200 (e.g., input and output devices, networking hardware, etc.) to the layers above it.

A media transport and presentation functionality 520 executes in the VOIP application layer 505 using a foreground application 525 that is operative with background processes 530. The foreground application 525 can typically be implemented using a UI host process, as described above in text accompanying FIG. 2, while the background processes may be implemented as agent host processes. As shown in FIG. 6, the foreground application 525 handles the task of compositing video for display in the UI, as indicated by reference numeral 605. The background processes 530 implement the tasks of video decoding, playback, and synchronization, as respectively indicated by reference numerals 610, 615, and 620. It is emphasized that these particular tasks are illustrative and that other tasks can also be performed and allocated between in-processing and cross-processing as may be needed to meet the requirements of a particular VOIP scenario.

The choice between in-process and cross-process media handling is made using a dummy moniker that is implemented in the foreground application 525, as described in more detail below, so that media transport and presentation is optimized to be as close as possible to minimize the latency perceived by the end user during a VOIP call experience.

FIG. 7 shows how media handling in this illustrative embodiment is broken into three processes, as respectively indicated by reference numerals 701, 702, and 703. In the first process 701, a media element 705 is instantiated in the foreground application 525. In this example, the media element 705 is realized as a Silverlight MediaElement which represents a player object, exposing various APIs, that can contain audio, video, or both and essentially functions as a region for displaying video on its surface and playing audio. A developer 710 denotes a dummy moniker 715 that is utilized in conjunction with the media element 705. As shown in FIG. 8, the dummy moniker indicates to the media element 705 whether the input to the element is from an in-process element 810, or cross-process element 815.

For the case of input from a cross-process element, referring back to FIG. 7, the foreground application relies on a texture 720 that is shared across all of the processes 701, 702, and 703 via a shared handle (as representatively indicated by reference numeral 725). Although the texture 720 is populated by the processes, the foreground application maintains ownership for compositing the texture into the foreground application scene as a foreground (i.e., UI host) process.

In the second process 702, a media engine 730, in response to instructions (not shown in FIG. 7) received from the third process 703 which contain either raw or decoded video frames, pumps audio and video into the texture 720 using the shared handle as a background process. Here, the media engine 730 typically executes user code 735, as a component of a Silverlight implementation, for example when drawing video frames into the texture 720 as an agent host (i.e., background) process.

The third process 703 is executed in a media pipeline 740 which populates data into the texture 720 through the shared handle 725. The third process 703 operates as the master process that initiates transactions with the other processes and receives media packets from the VOIP service 180 (FIG. 1), decodes the packets, renders audio to an appropriate audio device, and sends decoded streams to the media engine 730 for use in the second process 702.

FIG. 9 is an illustrative flowchart that depicts the interaction between the various elements and processes shown in FIG. 7. At block 905, the media element 705 is instantiated in the foreground application 525 which is utilized as a placeholder for the rendered output. The dummy moniker 715 is implemented, at block 910, for I/O redirection to the media element 705.

At block 915, the media pipeline 740, receives packets from the VOIP service in a single UI-less process, and will typically decode the received packets. The media pipeline also separately renders audio so that audio response is quickened without blocking from the video processing. The decoding can be performed in software, through an interface to the hardware layer, or using a combination of software and hardware. At block 920, the media pipeline 740 sends instructions responsively to a call, at block 925, from the media engine 730. The instructions can comprise either raw or decoded video frames. The instructions are continuously sent as streams to the media engine 730 as packets are received and decoded by the media pipeline 740. The media engine 730 then draws the received data into the shared texture 720 at block 930.

The claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. For instance, the claimed subject matter may be implemented as a computer-readable storage medium embedded with a computer executable program, which encompasses a computer program accessible from any computer-readable storage device or storage media. For example, computer readable storage media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). However, computer readable storage media do not include transitory forms of storage such as propagating signals, for example. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A portable device, comprising:

one or more processors;

a display;

a wireless modem configured to enable the portable device to communicate over a network;

one or more memory devices storing executable instructions which, when executed by the one or more processors, cause the portable device to

implement a media element as a placeholder for rendered audio-video output associated with a voice-over-Internet protocol (VOIP) call carried on the network;

utilize a dummy moniker configured to redirect input and output to and from the media element;

receive notification of an incoming VOIP call on a push notification channel supported on the network;

responsively to the notification, dispatch the incoming VOIP call to a background agent host process for processing;

launch a foreground user interface (UI) host process to present a UI to a user on the display;

inspect the dummy moniker to ascertain whether input to the media element is provided by the background agent host process; and

responsively to the dummy moniker, accept input at the media element from the background agent host process, the background agent host process configured to write into a texture that is commonly accessible by the foreground UI host process and background agent host process using a shared handle.

2. The portable device of claim 1 in which the executable instructions further cause the device to composite the texture into the UI using the foreground UI host process.

3. The portable device of claim 2 in which the executable instructions further cause the device to render the UI during the VOIP call.

4. The portable device of claim 1 in which the background agent host process executes for a duration of the VOIP call.

5. The portable device of claim 1 in which the background agent host process writes video into the texture.

6. The portable device of claim 1 in which the foreground UI host process terminates when the VOIP call is terminated.

7. The portable device of claim 1 in which the UI host process generates an incoming call notification that is written into the texture.

8. The portable device of claim 1 in which the executable instructions further cause the device to allocate hardware resources to the background agent host process to maintain a predetermined level of quality for the VOIP call.

9. The portable device of claim 1 in which the background agent host process receives and decodes media packets associated with the VOIP call and writes the decoded media packets into the texture.

10. The portable device of claim 1 in which the agent host process includes a keep-alive agent for periodically communicating with a VOIP server over the network.