Seamless web real-time communication support on mobile appliances

Techniques pertaining to seamless WebRTC support on mobile appliances are described. In one aspect, a method includes one or more processors of one or more gateway servers receiving from a browser-based application executed by a mobile device a request for access to multimedia provided by a multimedia access platform. The method also includes the one or more processors retrieving information related to a profile associated with a user of the mobile device from an identity and access management server. The method further includes the one or more processors enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia based at least in part on the profile associated with the user of the mobile device.

BACKGROUND

Web Real-Time Communication (WebRTC) is an application programming interface (API) being currently defined by standardization bodies including the World Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), the 3rdGeneration Partnership Project (3GPP), Mobile Open Alliance (OMA), and the Alliance for Telecommunications Industry Solutions (ATIS). WebRTC is designed to support browser-to-browser applications for voice calling, video chat, peer-to-peer (P2P) file sharing and access to other multimedia contents without plugins. It is an ongoing activity within IETF and W3C to enable real-time communications from or to web browsers using multimedia (e.g., audio, video and auxiliary data, such as calendar and address book). The purpose of WebRTC is to create a set of specifications that allows browsers to function as an effective platform for applications that use and exchange real-time, interactive communication in multimedia.

At the present stage, WebRTC is more mature in desktop environments than for mobile appliances. WebRTC is supported at this time for Google Chrome and Mozilla Firefox. However, additional capabilities (such as authentication/authorization, QoS, user interface for consent when receiving a call) are required to provide an acceptable user experience in mobile environment. There are a number of challenges with respect to providing WebRTC on mobile platforms. For example, as WebRTC is running as an over-the-top application, not as an optimized operator service, poor user experience of WebRTC and poor usage of scarce radio resources may result. Additionally, in order to avoid losing access to WebRTC services when a mobile device enters into a sleep mode, the sleep mode may be disabled on the mobile device but this work-around may reduce battery time due to battery drain. Moreover, a user may need to open an app or his/her web browser if WebRTC capable and to authenticate with the network before initiating or receiving real-time communication services (e.g., voice and video calls, messaging, presence), which is not a seamless experience. Furthermore, there is no support for IP address change on mobile devices, for example, due to network change (e.g., Wi-Fi, High-Speed Packet Access (HSPA), Evolved High-Speed Packet Access (HSPA+), or Long Term Evolution (LTE)). Besides, there are presently no semantics on the data channel.

DETAILED DESCRIPTION

The present disclosure describes techniques that support seamless WebRTC on mobile appliances and platforms across networks. For example, WebRTC on a mobile device may be implemented as a hybrid or native browser-based application running on, or executed by, the mobile device. The browser-based application may authenticate with a network and, upon successful authentication, access services including network-initiated services such as, for example, receiving calls, messaging, receiving presence states and/or notifications. Techniques of the present disclosure enhance user experience, avoid battery drain, and support IP address changes on the mobile device.

According to one aspect, a method may include one or more processors of one or more gateway servers, e.g., one or more WebRTC gateway servers, receiving from a browser-based application running on, or executed by, a mobile device a request for access to multimedia provided by a multimedia access platform, which may include either or both of an IP multimedia subsystem (IMS) and an extensible messaging and presence protocol (XMPP) platform. The method may also include the one or more processors retrieving information related to a profile associated with a user of the mobile device from an identity and access management (IAM) server. The method may further include the one or more processors enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia based at least in part on the profile associated with the user of the mobile device.

According to another aspect, a computing device may include memory, configured to store at least a set of instructions, and one or more processors coupled to the memory and configured to execute the set of instructions to perform operations. The operations may include: receiving from a browser-based application running on, or executed by, a mobile device a request for access to multimedia provided by a multimedia access platform, which may include either or both of an IP multimedia subsystem (IMS) and an extensible messaging and presence protocol (XMPP) platform; retrieving information related to a profile associated with a user of the mobile device from an IAM server; and enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia based at least in part on the profile associated with the user of the mobile device.

According to yet another aspect, a method may include communicating, by a browser-based application running on, or executed by, a mobile device, with an IAM server for authentication by the IAM server. The method may also include transmitting to a gateway server a request for access to multimedia provided by a multimedia access platform, which may include either or both of an IMS and an XMPP platform. The method may further include receiving from the multimedia access platform one or more types of multimedia.

According to still another aspect, a method may include registering, by a browser-based application running on, or executed by, a mobile device, with an IAM server of a network upon the browser-based application being launched. The method may also include transmitting to the gateway server one or more messages each of which having a respective level of a plurality of levels of quality of service (QoS).

According to a further aspect, a mobile device may include memory, configured to store at least a set of instructions, and one or more processors coupled to the memory and configured to execute the set of instructions to perform operations. The operations may include: executing a browser-based application to communicate with an IAM server for authentication by the IAM server; transmitting to a gateway server a request for access to multimedia provided by a multimedia access platform; and receiving from the multimedia access platform one or more types of multimedia.

Techniques of the present disclosure may be implemented, in part, in the forms of methods, devices, systems and network architecture in a number of ways. Example implementations are provided below with reference to the following figures.

Example Network Architecture

FIG. 1illustrates an example network architecture100in which support for seamless WebRTC on mobile appliances/platforms is implemented in accordance with embodiments of the present disclosure.

As shown inFIG. 1, example network architecture100includes a WebRTC service110, a multimedia access platform120, one or more identity and access management (IAM) servers130, one or more contacts servers140, one or more legacy systems150, one or more IP multimedia subsystem (IMS) clients160and one or more web servers170. WebRTC service110may include one or more WebRTC gateway servers112. The one or more legacy systems150include, for example, circuit-switched voice calls and short messaging service as well as public switched telephone network (PSTN). The one or more IMS clients160include, for example, voice calls, audio/video calls and messaging. Example network architecture100also includes one or more mobile devices each of which associated with a respective user. For illustrative purpose,FIG. 1shows mobile device182and mobile device192that are associated with user180and user190, respectively. One or more browser-based applications184are running, e.g., being executed, on mobile device182, and one or more browser-based applications194are running on, or executed by, mobile device192.

Those skilled in the art would appreciate that, although a certain number of network nodes and elements are illustrated inFIG. 1, techniques described herein also apply to alternative network architectures having different numbers of network elements/nodes. For instance, although two mobile devices (and their associated users and browser-based applications) are shown inFIG. 1, scope of the present disclosure covers implementations with different numbers of mobile devices (and associated users and browser-based applications). Moreover, for simplicity and not to obscure understanding of techniques of the present disclosure, certain network elements/nodes typically found in telecommunication networks are not illustrated inFIG. 1.

Example network architecture100utilizes multimedia access platform120, to provide seamless WebRTC support for mobile appliances/platforms. In example network architecture100, one or more WebRTC applications are executed in WebRTC-capable browsers as hybrid or native applications. For example, one or more browser-based application184and194are run on mobile devices182and192, respectively. Multimedia access platform120is an external system to the one or more WebRTC gateway servers112of WebRTC service110. In some embodiments, multimedia access platform120may include an IP multimedia subsystem (IMS). In some alternative embodiments, multimedia access platform120may include an extensible messaging and presence protocol (XMPP) platform. In other embodiments, multimedia access platform120may include a dual platform supporting IMS and XMPP interworking, which includes protocol translation and identity mapping. That is, multimedia access platform120may include either or both of an IMS and an XMPP platform. The one or more IAM servers130support single sign-on (SSO) to authenticate and authorize WebRTC users (e.g., users180/190). The one or more IAM servers130contain a profile of each WebRTC users to support key management and identity mapping between WebRTC users and multimedia access platform120. For instance, the one or more browser-based applications184run on mobile device182, which is associated with user180, may access some or all of the one or more IMS clients160through multimedia access platform120upon the user180being authenticated and authorized by the one or more IAM servers130. Which one(s) of the one or more IMS clients160may be accessed by the one or more browser-based applications184depends on the user profile of user180. Likewise, which one(s) of the one or more IMS clients160may be accessed by the one or more browser-based applications194depends on the user profile of user190. The one or more web servers170host WebRTC web page which may be accessed by the one or more browser-based applications184and the one or more browser-based applications194. The one or more contacts server140are external to the one or more web servers170and contain information related to contacts of each WebRTC users such as, for example, some or all of the following pieces of information: name, phone number(s), physical address(s), email address(s), account name(s), etc. In various embodiments, at least one of the one or more contacts servers140may be an Extensible Markup Language (XML) Data Management Server (XDMS).

The one or more WebRTC gateway servers112abstract the complexity of the IMS signaling protocol such as, for example, Session Initiation Protocol (SIP) for WebRTC users, e.g., mobile devices182/192. In various embodiments, the one or more WebRTC gateway servers112also translate media between WebRTC and IMS domains when media is anchored in a service provider's network. For instance, in translating media, the one or more WebRTC gateway servers112may perform media adaption including, in some cases, translation between codecs.

In a typical scenario according to the present disclosure, a user (e.g., user180or190), or the WebRTC application (e.g., browser-based application184or194) executed by the user's mobile platform (e.g., mobile device182or192), performs authentication with the one or more IAM servers130to obtain authorization. The authorization triggers an IMS registration and registering the authorized state of the user with the WebRTC service110(e.g., in the one or more WebRTC gateway servers112). The one or more WebRTC gateway servers112interface multimedia access platform120and the WebRTC application (e.g., browser-based application184or194), and the one or more WebRTC gateway servers112may perform transcoding in needed (e.g., translating media between WebRTC and IMS domains by performing media adaption such as translation between codecs). The one or more WebRTC gateway servers112may also connect to other resources such as, for example, one or more contacts servers140.

Additionally, communications between mobile devices182and mobile device192may be established for peer-to-peer media. For example, mobile devices182and mobile device192may support dedicated bearers to provide guaranteed quality of service or priority compared to other services.

Techniques of the present disclosure do not introduce any new change that would deteriorate the behavior or performance of the existing LTE CSFB service, and do not require regression testing. Moreover, techniques of the present disclosure add a new call flow and have no known or major conflict with existing call flows defined by the 3GPP standards. In various embodiments, techniques of the present disclosure may be implemented in MSCs of UMTS and GSM networks.

Example Network Architecture

FIG. 2illustrates an example mobile device architecture200in accordance with an embodiment of the present disclosure.

As shown inFIG. 2, example mobile device architecture200includes WebRTC application210, user interface220, middleware230, operating system240, one or more drivers250, network interface260, baseband circuitry265, universal integrated circuit card (UICC)270, one or more other devices280and one or more input/output devices290. Example mobile device architecture200may be implemented in any one of the mobile platforms in accordance with the present disclosure. For instance, example mobile device architecture200may be implemented in mobile device182and/or mobile device192. Referring toFIG. 1andFIG. 2, WebRTC application210communicates with a WebRTC gateway server (e.g., one or more WebRTC gateway servers112) and/or the WebRTC application (e.g., browser-based application184or194) executed by another mobile platform (e.g., mobile device182or192) via user interface220, middleware230, operating system240, baseband circuitry265and network interface260.

For voice and video services, WebRTC application210do not rely on best-effort delivery (i.e., no attempt to provide guaranteed quality of service (QoS) level or priority compared to other services). To provide an acceptable user experience, for voice and/or video traffic, WebRTC application210may use dedicated bearers with guaranteed bit rate (GBR) instead of using non-GBR bearer (such as the default bearer which is used for transmission control protocol (TCP) traffic) to transport voice and/or video packets. Bearers may include signaling and media (e.g., Secure Real-time Transport Protocol). Bearer associated with media may provide GBR similar to voice-over-IP (VoIP) LTE services. In some embodiments, signaling may be similar in characteristics as signaling for IMS.

In some embodiments, QoS for the bearers used for IMS services may be defined in the manners described below. Bearers for IMS signaling may be defined as non-GBR, with a delay budget of 150 ms and 10−6packet loss rate. Bearers for media associated with voice calls may be defined as GBR, with a delay budget of 100 ms and 10−2packet loss rate. Bearers for media associated with video calls may be defined as GBR, with a delay budget of 150 ms and 10−3packet loss rate.

For WebRTC, dedicated bearers may be used to receive better treatment (e.g., for better user experience), and may be defined in traffic flow templates. Traffic flow templates may be defined as packet filters associated with an Encapsulated PostScript (EPS) bearer. A packet filter may be associated with a protocol, a specific port, an IP packet destination or source address, or a combination of two or more of the above. For WebRTC, the IP address used may be the IP address of the WebRTC gateway for the signaling protocol (e.g., HTTP) and media protocol (e.g., SRTP).

In some embodiments, QoS class identifiers (QCIs) or re-use of QCIs associated with IMS services may be defined for WebRTC services. Alternatively, GBR bearers may be used as resources permanently allocated by admission control. These resources may be allocated at the bearer establishment or modification by an admission control function.

At least for EPS bearers, QoS parameters may include QCI and Allocation and Retention Priority (ARP). QCIs may be used by WebRTC application210to define one or more of the following: type of resource (e.g., either GBR or non-GBR), priority of the queue associated with a particular bearer, packet delay budget (e.g., possible latency of data packets transported between UE and packet-based gateway), and packet loss rate (PLR). PLR is defined as the rate of a number of service data units (SDUs) not successfully transported to the upper layer to a number of total SDUs processed by the link layer of the transmitting end for non-congested cases. ARP may be used by WebRTC application210to determine whether to accept or reject a request for establishing or modifying bearers in case of limited resources.

In some embodiments, WebRTC application210may support evolved packet system bearer (i.e., a bearer for LTE) corresponding to package data protocol (PDP) context for GPRS, UMTS (3G), HPSA or HSPA+.

In some embodiments, either a secondary PDP context may be activated or a primary PDP context may be modified to support WebRTC. Given the requirements of WebRTC (e.g., voice and video), this service may be supported on HSPA or HSPA+.

Example Push Mechanism

FIG. 3illustrates an example push mechanism300in accordance with an embodiment of the present disclosure.

As shown inFIG. 3, example push mechanism300includes a mobile device310and a WebRTC gateway server320, and the mobile device310includes a WebRTC application312and an operating system314. Example push mechanism300may be implemented in example network architecture100, e.g., between one or more WebRTC gateway servers112of WebRTC service110and mobile device182and/or192.

At step1of example push mechanism300, an event from network is received by WebRTC gateway server320. The event may be, for example, incoming call, incoming message or event such as presence or network deregistration. At step2of example push mechanism300, WebRTC gateway server320sends a push signal/message to operating system314of mobile device310. In turn, at step3of example push mechanism300, operating system314wakes up WebRTC application312of mobile device310. At step4of example push mechanism300, WebRTC application312queries WebRTC gateway server320about the event (also referred to as the push event), e.g., using HTTP APIs. In some embodiments, when operating system314wakes up WebRTC application312, operating system314may send information to WebRTC application312to indicate what the push event is. WebRTC gateway server320stores information about which type of device(s) it is connected to in order to select the proper push mechanism, as the push mechanism used may vary from device to device. For instance, depending on what type of device mobile device310is, the push mechanism may be one of the following: Mobile Status Notification Protocol (MSNP), Apple Push Notification Service (APNS), Android Cloud to Device Messaging (C2DM) or Google Cloud Messaging for Android (GCM).

WebRTC application312may perform a number of API calls, and WebSocklets may be used to carry media.

Example push mechanism300may also be used to provide a periodic registration of the mobile device310with the network.

Example Computing Device

FIG. 4illustrates a block diagram of an example computing device400in accordance with an embodiment of the present disclosure.

As shown inFIG. 4, example computing device400includes memory402, one or more processors404coupled to memory402, communication module406coupled to the one or more processors404, and WebRTC service module408coupled to the one or more processors404. Example computing device400may be implemented in a gateway server such as any one of the one or more WebRTC gateway servers112of WebRTC server110ofFIG. 1. Communication module406is controlled by the one or more processors404to communicate with other devices. Although WebRTC service module408is shown as a discrete, separate module from the one or more processors404, in some embodiments WebRTC service module408is a logical concept and may be implemented as an integral part of the one or more processors404. The one or more processors404may cause WebRTC service module408to perform operations described below.

Memory402may store at least a set of instructions. The one or more processors404may execute the set of instructions to perform a number of operations. The operations may include: receiving from a browser-based application executed by a mobile device a request for access to multimedia provided by a multimedia access platform, which may include either or both of an IMS and an XMPP platform; retrieving information related to a profile associated with a user of the mobile device from an IAM server; and enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia based at least in part on the profile associated with the user of the mobile device.

In various embodiments, the one or more processors404may be further configured to perform operations including enabling the browser-based application to receive from the multimedia access platform the one or more types of multimedia after the user of the mobile device is authenticated by the IAM server.

In various embodiments, the one or more processors404may be further configured to perform operations including communicating with the multimedia access platform in accordance with SIP.

In various embodiments, in enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia, the one or more processors404may be configured to translate media between the browser-based application and domains of the multimedia access platform.

In various embodiments, the one or more processors404may be further configured to perform operations including enabling the browser-based application to retrieve from an XDMS information of contacts associated with the user of the mobile device.

In various embodiments, the one or more processors404may be further configured to perform operations including communicating to the browser-based application by a push mechanism, and receiving a query from the browser-based application in response to the communicating. In various embodiments, the communicating to the browser-based application may include communicating to an operating system of the mobile device to wake up the browser-based application from a sleep mode. In various embodiments, the communicating to the browser-based application may include communicating to the browser-based application in response to receiving a notification regarding an event. In various embodiments, the event may include an incoming call for the user of the mobile device, an incoming message for the user of the mobile device, a presence state, or network degradation.

Example Mobile Device

FIG. 5illustrates a block diagram of an example mobile device500in accordance with an embodiment of the present disclosure.

As shown inFIG. 5, example mobile device500includes memory502, one or more processors504coupled to memory502, communication module506coupled to the one or more processors504, input/output module508coupled to the one or more processors504, and UICC510coupled to the one or more processors504. Example mobile device500may be implemented in mobile device such as mobile device182and/or mobile device192ofFIG. 1. Communication module506is controlled by the one or more processors504to communicate with other devices.

Memory502may store at least a set of instructions. The one or more processors504may execute the set of instructions to perform a number of operations. The operations may include: executing a browser-based application to communicate with an IAM server for authentication by the IAM server; transmitting to a gateway server a request for access to multimedia provided by a multimedia access platform; and receiving from the multimedia access platform one or more types of multimedia.

In various embodiments, the browser-based application may include a WebRTC application in accordance with W3C, and the browser-based application may include a native or hybrid web application.

In various embodiments, the one or more processors may be further configured to perform operations including retrieving from an XDMS information of contacts associated with a user of the mobile device.

In various embodiments, the one or more processors may be further configured to perform operations including receiving a communication from the gateway server, and transmitting a query to the gateway server in response to receiving the communication. In various embodiments, the receiving the communication may include receiving the communication by a push mechanism. In various embodiments, the receiving the communication from the gateway server may include receiving the communication from the gateway server in response to the gateway server receiving a notification regarding an event. In various embodiments, the event may include an incoming call for the user of the mobile device, an incoming message for the user of the mobile device, a presence state, or network degradation.

In various embodiments, the one or more processors may be further configured to perform operations including accessing one or more input devices or one or more output devices of the mobile device to support the browser-based application, and accessing a universal integrated circuit card (UICC) of the mobile device to support the browser-based application.

In various embodiments, the one or more processors may be further configured to perform operations including receiving periodically a wake-up message from the gateway server, and transmitting a response message to the gateway server in response to receiving the wake-up message.

In various embodiments, the one or more processors may be further configured to perform operations including transmitting a notification to the gateway server in response to a change of an IP address or a network associated with the mobile device.

Example Processes

Example processes described herein are illustrated as a collection of referenced acts arranged in a logical flow graph, which represent a sequence that can be implemented in hardware, software, or a combination thereof. In the context of software, the acts represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the acts are described is not intended to be construed as a limitation, and any number of the described acts can be combined in any order and/or in parallel to implement the example processes.

FIG. 6illustrates a flow diagram of an example process600implemented in a computing device in accordance with an embodiment of the present disclosure. Process600may be implemented by the one or more WebRTC gateway servers112ofFIG. 1or example computing device400ofFIG. 4. Further, process600may include one or more operations, actions, or functions depicted by one or more blocks602,604and606. For illustrative purpose, operations of process600are described below form the perspective of one or more processors of the one or more WebRTC gateway servers112of WebRTC110ofFIG. 1. Process600may begin at602.

At602, one or more processors of one or more gateway servers112receive from a browser-based application (e.g., WebRTC-capable browser-based application184or194) executed by a mobile device (e.g., mobile device182or192) a request for access to multimedia provided by a multimedia access platform.

At604, the one or more processors retrieve information related to a profile associated with a user of the mobile device from an IAM server (e.g., one or more IAM servers130).

At606, the one or more processors enable the browser-based application to receive from the multimedia access platform one or more types of multimedia based at least in part on the profile associated with the user of the mobile device.

In various embodiments, the enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia may include enabling the browser-based application to receive from the multimedia access platform the one or more types of multimedia after the user of the mobile device is authenticated by the IAM server.

In various embodiments, the enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia may include communicating with the multimedia access platform in accordance with a signaling protocol of the multimedia access platform. The multimedia access platform may include either or both of an IMS and an XMPP platform.

In various embodiments, the enabling the browser-based application to receive from the multimedia access platform one or more types of multimedia may include translating media between the browser-based application and domains of the multimedia access platform.

In various embodiments, the browser-based application may include a WebRTC application in accordance with the W3C, and the browser-based application may include a native or hybrid web application.

In various embodiments, process600may further include the one or more processors enabling the browser-based application to retrieve from a data management server information of contacts associated with the user of the mobile device. In various embodiments, the data management server may include an XDMS.

In various embodiments, the method may further include communicating to the browser-based application, and receiving a query from the browser-based application in response to the communicating. In various embodiments, the communicating may include communicating by a push mechanism. In various embodiments, the communicating to the browser-based application may include communicating to the browser-based application in response to receiving a notification regarding an event. In various embodiments, the event may include an incoming call for the user of the mobile device, an incoming message for the user of the mobile device, a presence state, or network degradation.

FIG. 7illustrates a flow diagram of an example process700implemented in a mobile device in accordance with an embodiment of the present disclosure. Process700may be implemented by browser-based application184or194executed by mobile device182or192ofFIG. 1, WebRTC application210of mobile device architecture200ofFIG. 2, or one or more processors504of example mobile device500ofFIG. 5. Further, process700may include one or more operations, actions, or functions depicted by one or more blocks702,704and706. For illustrative purpose, operations of process700are described below form the perspective of browser-based application184of mobile device182ofFIG. 1. Process700may begin at702.

At702, browser-based application184executed by a mobile device182communicates with an IAM server (e.g., one or more IAM servers130) for authentication by the IAM server.

At704, browser-based application184transmits to a gateway server (e.g., one or more WebRTC gateway servers112) a request for access to multimedia provided by a multimedia source (e.g., multimedia access platform120).

At706, browser-based application184receives from the multimedia access platform one or more types of multimedia.

In various embodiments, browser-based application184may include a WebRTC application in accordance with W3C, and the browser-based application may include a native or hybrid web application.

In various embodiments, process700may further include browser-based application184retrieving from a data management server information of contacts associated with a user of the mobile device. In various embodiments, the data management server may include an XDMS.

In various embodiments, the method may further include browser-based application184receiving a communication from the gateway server, and transmitting a query to the gateway server in response to receiving the communication. In various embodiments, the receiving the communication may include receiving the communication by a push mechanism. In various embodiments, the receiving the communication from the gateway server may include receiving the communication from the gateway server in response to the gateway server receiving a notification regarding an event. In various embodiments, the event may include an incoming call for the user of the mobile device, an incoming message for the user of the mobile device, a presence state, or network degradation.

In various embodiments, process700may further include browser-based application184transmitting a notification to the gateway server in response to a change of an IP address associated with the mobile device.

In various embodiments, process700may further include browser-based application184transmitting a notification to the gateway server in response to a change of a network associated with the mobile device.

FIG. 8illustrates a flow diagram of an example process800implemented in a mobile device in accordance with an embodiment of the present disclosure. Process800may be implemented by browser-based application184or194executed by mobile device182or192ofFIG. 1, WebRTC application210of mobile device architecture200ofFIG. 2, or one or more processors504of example mobile device500ofFIG. 5. Further, process800may include one or more operations, actions, or functions depicted by one or more blocks802and804. For illustrative purpose, operations of process800are described below form the perspective of browser-based application184of mobile device182ofFIG. 1. Process800may begin at802.

At802, browser-based application184executed by a mobile device182registers with an IAM server (e.g., one or more IAM servers130) upon the browser-based application being launched.

At804, browser-based application184transmits to the gateway server one or more messages. Each of the messages has a respective level of a plurality of levels of quality of service (QoS).

In various embodiments, the plurality of levels of QoS may include a first QoS level for IMS signaling with non-GBR and a delay budget of 150 ms and 10−6packet loss rate, a second QoS level for voice calls with GBR and a delay budget of 100 ms and 10−2packet loss rate, and a third QoS level for video calls with GBR and a delay budget of 150 ms and 10−3packet loss rate.

In various embodiments, the one or more messages may include one or more signaling messages and one or more bearer messages.

In various embodiments, the one or more bearer messages may include at least a bear message with GBR or a bear message with non-GBR.

In various embodiments, in registering, browser-based application184may perform operations including: retrieving credential information from a UICC of the mobile device; transmitting the credential information to the IAM server for authentication by the IAM server; and receiving one or more messages from the IAM server indicating authorization to access multimedia provided by a multimedia access platform, which may include either or both of an IMS and an XMPP platform.

In various embodiments, process800may further include browser-based application184communicating with a data input or output device of the mobile device. The data input or output device of the mobile device may include a camera, a microphone, or both.

In various embodiments, process800may further include browser-based application184receiving from a multimedia access platform one or more types of multimedia. At least one of the one or more messages may include a request for access to multimedia provided by the multimedia access platform.

CONCLUSION