Supporting quality of service for media communications

A client device (e.g., user equipment or “UE”) may be configured to engage in a media communication session, such as a WebRTC session, with another client device. The client devices may separate a quality of service (QoS) specification from a QoS flow definition, to allow for separate interactive connectivity establishment (ICE) negotiation. The QoS specification may cover all segments of a connection for the media communication session. For example, QoS may be requested for a case where a server (e.g., a Traversal Using Relay Network Address Translation (TURN) server) is hosted by a mobile network operator (MNO). The QoS specification and the QoS flow description may be linked.

TECHNICAL FIELD

This disclosure relates to transmission of media data via a computer network in real time.

BACKGROUND

Client devices, also referred to as “user equipment” or “UE,” may be configured to exchange audio and/or video data with each other over a computer network. The network may include, for example, routers, hubs, bridges, switches, servers, security devices, and the like, for transporting data between the client devices. The client devices may be smartphones, tablets, personal computers, laptops, or the like. The exchange of audio and/or video data between client devices may be performed in real time, e.g., as a voice or video call.

SUMMARY

In general, this disclosure describes techniques for applying quality of service (QoS) to media communications between client devices. For example, QoS may be applied to a Web Real-Time Communication (WebRTC) session between two client devices. The techniques of this disclosure may include separating QoS specifications from QoS flow definitions, which allows for separate interactive connectivity establishment (ICE) negotiation. The QoS specification may cover all segments of a connection for the media communication session. For example, QoS may be requested for a case where a server (e.g., a Traversal Using Relay Network Address Translation (TURN) server) is hosted by a mobile network operator (MNO). The QoS specification and the QoS flow description may be linked.

In one example, a method of applying quality of service to a media communication session includes determining, by a first client device, a list of interactive connectivity establishment (ICE) candidates for a second client device; determining, by the first client device, valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, sending, by the first client device, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establishing, by the first client device, the media communication session with the second client device using the determined one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification and the one of the QoS flows for the media communication session; and providing data to an application function to apply, by the first client device, QoS to the media communication session according to the QoS specification.

In another example, a first client device for applying quality of service to a media communication session includes a memory configured to store media data; and one or more processors implemented in circuitry and configured to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

In another example, a computer-readable storage medium has stored thereon instructions that, when executed, cause a processor of a first client device to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

In another example, first client device for applying quality of service to a media communication session includes means for determining a list of interactive connectivity establishment (ICE) candidates for a second client device; means for determining valid ICE candidates in the list of ICE candidates; means for sending, for one or more of the valid ICE candidates, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; means for establishing the media communication session with the second client device using the determined one of the valid ICE candidates; means for determining an association between a QoS specification and the one of the QoS flows for the media communication session; and means for providing data to the AF to apply QoS to the media communication session according to the QoS specification.

In another example, a method of applying quality of service to a media communication session includes receiving, from a first client device and by a server device executing an application function (AF), data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device, the AF providing media control for a media communication session between the first client device and a second client device; receiving, from the first client device and by the server device, data representing an association between one of the QoS flows and an associated QoS specification; and applying, by the server device, QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

In another example, a server device for applying quality of service to a media communication session includes a memory configured to store associations between quality of service (QoS) flows and one or more valid interactive connectivity establishment (ICE) candidates for a first client device; and one or more processors implemented in circuitry and configured to: execute an application function (AF), the AF providing media control for a media communication session between the first client device and a second client device; receive, from the first client device, data representing the associations between QoS flows and the one or more valid ICE candidates for the first client device; receive, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and apply, by the server device, QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

In another example, a computer-readable storage medium has stored thereon instructions that cause a processor of a server device to: executing an application function (AF), the AF providing media control for a media communication session between a first client device and a second client device; receive, from the first client device, data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device; receive, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and apply QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

In another example, a server device for applying quality of service to a media communication session includes means for executing an application function (AF), the AF providing media control for a media communication session between a first client device and a second client device; means for receiving, from the first client device, data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device; means for receiving, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and means for applying QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an example network100in which client devices110A,110B (client devices110) exchange media data with each other. In this example, network100includes client devices110and server device102. Server device102includes application server106and executes application function104. In general, application function104provides media control, while application server106provides media content traffic, e.g., for communication session114between client devices110.

Client devices110include respective agents112A,112B (agents112). Agents112may represent Web Real-Time Communication (WebRTC) agents. Agents112may include respective WebRTC application programming interfaces (APIs). In general, WebRTC represents an API and a set of protocols for real-time communication, e.g., for communication session114. For example, client device110A may use agent112A to perform communication session114with client device110B via the API and protocols of WebRTC.

Client device110A may initially generate a request, such as a session description protocol (SDP) offer. For example, client device110A may call “createOffer” on an RTCPeerConnection object via agent112A. The SDP offer may include information about agent112A, e.g., encoder/decoder(s) supported, whether communication session114will include audio and/or video, and other connection-related information. In addition, the SDP offer may include a list of one or more interactive connectivity establishment (ICE) candidates, including port and IP pairs that client device110B can use to establish communication session114with client device110A.

To construct the list of ICE candidates, client device110A may send one or more requests to a Session Traversal of UDP (STUN) server, e.g., server device102. The STUN server may provide public port and IP addresses to client device110A for client device110A. Client device110A may then add each port/IP address pair to the list of ICE candidates. After constructing the list of ICE candidates, client device110A may send the SDP offer to client device110B via a signaling channel between agents112A and112B, e.g., using WebRTC.

After receiving the SDP offer, client device110B may generate an SDP answer. Client device110B may gather a list of ICE candidates for itself and generate the SDP answer to include the list of ICE candidates, then send the SDP answer to client device110A. Client devices110may then check the various port/IP address pairs from the lists received from each other and send each pair a STUN request. If a response is received from the other one of client devices110, the one of client devices110that sent the response can determine that the corresponding port and IP pair for the request is a valid ICE candidate.

After client devices110finish testing the port/IP pairs, client devices110may determine which of the valid pairs to use. Client devices110may then exchange media data via the selected, valid pairs.

Additionally, server device102may request quality of service (QoS) data from client devices110A,110B regarding communication session114. In accordance with the techniques of this disclosure, server device102may submit a QoS request to request QoS reference data after the ICE negotiation between client devices110. The QoS request may include data that associates QoS flow descriptions with QoS specifications, data that describes a service data flow for which a requested QoS is provided, and data representing a reference to the QoS specification.

After one of client devices110, e.g., client device110A, identifies a valid ICE candidate, client device110A may associate the new QoS flows associated with the ICE candidate and determine whether to update the QoS association with server device102(and in particular, application function104). In response, server device102may determine whether to identify the corresponding QoS flows to the remote pair and request that QoS be applied to it as well.

FIG.2is a block diagram illustrating an example client device120according to techniques of this disclosure. In this example, client device120includes user interfaces122, 5G Media Streaming (5GMS) aware application124, media session handler (MSH)126, access client128, agent130, network interface136, memory140, decoders132, renderers134, display136, and speakers138.

User interfaces122may represent a variety of user interfaces such as a touchscreen, buttons, joysticks, a microphone, a camera, peripherals such as earbuds, external microphones, external cameras, game controllers, keyboards, mice, or the like. In general, user interfaces122allow a user of client device120to interact with and provide input to client device120. For example, the user may use client device120to engage in a media communication session with another user of a different client device, such as a Web Real-Time Communication (WebRTC) session. As part of the WebRTC session, the user may send and receive voice data, sound data, video data, still image data, extended reality (XR) data such as augmented reality (AR) data, virtual reality (VR) data, mixed reality (MR) data, or the like.

User interfaces122may pass received media data for the media communication session to encoders142for encoding. Encoders142may include audio, image, video, or other such encoders for encoding media data for network transmission. Encoders142may provide the encoded media data to 5GMS aware application124.

5GMSd aware application124may receive user input data from user interfaces122and/or encoded media data from encoders142. 5GMS aware application124may pass information representative of the user input data and encoded media data to MSH126, which may also receive information from a 5GMS application function (AF) executed by a separate server device (not shown inFIG.2), such as AF104ofFIG.1.

MSH126may provide the information to access client128, which may also receive one or more media streams from a 5GMS application server (AS) executed by a separate server device (not shown inFIG.2), such as AS106ofFIG.1.

Access client128may initialize a media communication session, such as a WebRTC session, as discussed below. According to the techniques of this disclosure, the media communication session may have an associated quality of service (QoS) configuration. For example, the QoS configuration may depend on whether the media communication session includes audio data, video data, XR data, or a combination thereof, whether accurate user position information is needed, an amount of bandwidth needed for the media communication session, or the like. Access client128may receive media data for the media communication session and provide the media data to decoders132. Media data may also be stored (e.g., buffered) in memory140. Memory140may also store instructions for execution by one or more processors, e.g., software or firmware instructions for any of the various components of client device120, such as 5GMS aware application124, MSH126, access client128, agent130, decoders132, and/or renderers134.

Agent130may correspond to one of agents112ofFIG.1. Agent130may represent a WebRTC agent that acts as an API and a set of protocols for real-time communication for the media communication session. As discussed above, agent130may construct a list of interactive connectivity establishment (ICE) candidates. Agent130may send and receive data via network interface136, which may represent a wireless or wired network interface, such as a WiFi interface, an 802.11 interface, an Ethernet interface, or the like.

Agent130may determine a list of ICE candidates for another client device, as well as for itself. For example, agent130may query a STUN server to determine its various public IP addresses and ports. Agent130may then form the list of ICE candidates to include one or more of the ICE candidates indicated in the data received from the STUN server. Agent130may further receive data representing one or more STUN and/or TURN servers prior to querying the STUN and/or TURN servers. In some examples, server device102may execute AF104to act as both a STUN server and a TURN server.

Agent130may use a TURN server to establish a media communication session with another client device. For example, agent130of client device120may send an invite to the other client device and receive an acceptance in response to the invite. The invite may include the list of ICE candidates for client device120, and the acceptance may include a list of ICE candidates for the other client device. The other client device may also be referred to as a peer client device.

Agent130may then validate each ICE candidate in the list for the other client device. For example, agent130may send a STUN request to the IP address and port for a particular ICE candidate for the other client device. If a response is received for the STUN request, agent130may determine that the corresponding ICE candidate is valid. After determining the valid ICE candidates, agent130may negotiate with the other client device to determine which ICE candidates for each device are to be used for the media communication session.

In accordance with the techniques of this disclosure, agent130may specify one or more quality of service (QoS) flows associated with each of the valid ICE candidates to server device102(FIG.1). Thus, server device102may use this information to determine an appropriate QoS flow for a particular one of the ICE candidates. In this manner, data to be sent to the other client device as part of the media communication session, i.e., directed to the public IP address and port for the other client device, may be sent via a corresponding QoS flow. In this manner, QoS may be applied to the media communication session.

Decoders132may include audio decoders, video decoders, or the like. Decoders132may receive media data exchanged via the media communication session and decode the received media data. Decoders132may provide the decoded media data to renderers134, which may render the media data. For example, renderers134may compose various pieces of separately decoded media data together for simultaneous playback and provide rendered image or video data to display136and rendered audio data to speakers138.

In this manner, client device120represents an example of a first client device for applying quality of service to a media communication session, the first client device including: a memory configured to store media data; and one or more processors implemented in circuitry and configured to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

FIG.3is a block diagram illustrating an example Web Real-Time Communication (WebRTC) architecture156. Agents112ofFIG.1and agent130ofFIG.2may include components similar to those shown in WebRTC architecture156ofFIG.3. WebRTC architecture156forms part of system150for performing WebRTC.

In this example, WebRTC architecture156includes WebRTC application programming interface (API)158and a set of protocols that enable real-time communication. The WebRTC protocols enable any two WebRTC agents to negotiate and setup a bidirectional and secure real-time communication channel. WebRTC API156, in one example, exposes a JavaScript-based API to enable the development of applications that make use of existing multimedia capabilities of a client device to establish real-time communication sessions. While JavaScript is one example, access to the WebRTC set of protocols is possible through other programming languages as well.

The RTCWeb group of the Internet Engineering Task Force (IETF) develops and maintains WebRTC protocols. The Worldwide Web Consortium (W3C) develops the WebRTC API.

As shown inFIG.3, WebRTC API158can be decomposed into three layers: a first layer including an API for web developers that includes a MediaStream object, an RTCPeerConnection object, and an RTCDataChannel object; a second layer including an API for a web browser and user agent implementers and providers; and a third layer including an overridable API for audio/video capture and rendering and for network input/output, which the browser implementers can hook implementations to.

In the example ofFIG.3, system150includes web application programming interface (API)154and WebRTC architecture156. Web API154receives data from one or more web applications152A-152N (web apps152). Web API154may provide data from web apps152to WebRTC architecture156. WebRTC architecture156in this example includes WebRTC API158, session management and abstract signaling unit160, voice engine170, video engine180, transport unit190, audio capture 162, video capture 164, and network input/output (I/O)166.

Voice engine170includes encoder/decoder (CODEC)172, jitter buffer174, and enhance engine176. CODEC172may include, for example, an Internet speech audio codec (iSAC) and/or an Internet low bitrate codec (iLBC). Jitter buffer174may include both a jitter buffer and an error concealment unit. In some examples, jitter buffer174may correspond to a NetEQ implementation of a jitter buffer. Enhance engine176may include an echo cancelation unit and/or a noise reduction unit.

Video engine180includes CODEC182, jitter buffer184, and enhance engine186. CODEC182may conform to one or more of a variety of video coding standards, such as ITU-T H.264/Advanced Video Coding (AVC), ITU-T H.265/High Efficiency Video Coding (HEVC), ITU-T H.266/Versatile Video Coding (VVC), VP8, VP9, or the like. Jitter buffer184buffers received video data until the video data is ready to be decoded. Enhance engine186may enhance decoded video data as a post-loop processing, e.g., with interpolation to upsample images to a higher display resolution, frame-rate upconversion (FRUC), post-loop filtering (e.g., artificial intelligence based filtering), or the like.

Transport unit190includes protocols192, multiplexing unit194, and peer-to-peer (P2P) STUN/TURN/ICE unit196. Protocols192may include one or more of a variety of transport protocols, such as Real-time Transport Protocol (RTP), Secure RTP (SRTP), or the like. Multiplexing unit194may multiplex a variety of streams together, such as one or more audio streams, one or more video streams, and other media (e.g., timed text/closed captions). PTP STUN/TURN/ICE unit196generally issues STUN and/or TURN requests as part of ICE negotiation to establish a P2P connection with another client device. P2P STUN/TURN/ICE unit196may also perform the techniques of this disclosure, e.g., including QoS flow data with ICE candidates when sending the ICE candidate data to a server device executing an AF, such that the server device can associate the ICE candidate with an appropriate QoS flow.

Audio capture 162 may be a microphone for capturing user voice data or other sound data. Video capture 164 may include one or more cameras for capturing image or video data. Network I/O unit166may include one or more network interfaces, such as wired or wireless interfaces, e.g., 802.11 interfaces, WiFi interfaces, Ethernet interfaces, or the like.

FIG.4is a conceptual diagram illustrating an example WebRTC protocol stack200. WebRTC stack200includes components such as a voice engine, a video engine, and a transport component. The transport component provides a secure transport channel for both parties (e.g., client devices110ofFIG.1) to communicate. The transport component may use a Real-time Transport Protocol (RTP) stack that runs over datagram transport layer security (DTLS) and leverages the secure real-time transport protocol (SRTP) profile.

In the example ofFIG.4, WebRTC stack200includes media path components202and signaling path components204. Media path components202include time-critical components206and non-time-critical components208. Time-critical components include CODEC210, SRTP212, and Secure RTP Control Protocol (SRTCP)214. Non-time-critical components include stream control transmission protocol (SCTP)216. Datagram transport layer security (DTLS) protocol218supports each of the various media path components above DTLS protocol218in the protocol stack. Likewise, ICE/STUN/TURN protocols220support the various components above ICE/STUN/TURN protocols220in the stack. Data for each of media path components202may be encapsulated according to user datagram protocol (UDP)222and encapsulated and transported according to Internet protocol (IP)224. IP224may be IPv4, IPv6, or other IP-layer protocol.

Signaling path components204in this example include session initiation protocol (SIP)226, short message peer-to-peer (SMPP) protocol228, session description protocol232, and other protocols230. These protocols may use Web Sockets234, server-sent events (SSE), XML HTTP Request (XHR)238, and other240such services. These various services may operate over hypertext transfer protocol (HTTP)242. HTTP242may operate over transport layer security (TLS) protocol244to provide security, e.g., encryption. The TLS-secured HTTP data may be transported according to transmission control protocol (TCP)246, which may be transferred according to IP224.

FIG.5is a state transition diagram illustrating an example process250for initiating media communication sessions via WebRTC. Once a WebRTC session has been initiated, a WebRTC client may begin in stable state256. In stable state256, it is assumed that there is no current, ongoing exchange of an offer and answer. To initiate each media communication session (such as an audio communication session or a video communication session), the WebRTC client may send or receive offers representing SDP data including, for example, supported CODECs, formatting, or the like.

In stable state256, the WebRTC client may receive a local offer from a local element of the client device including the WebRTC client. In response to receiving the local offer (setLocal(OFFER)), the WebRTC client may transition to have-local-offer state258. The WebRTC client may then send the offer to the peer WebRTC client. In response to receiving an answer from the peer WebRTC client (setRemote(PRANSWER)), the WebRTC client may transition to have-remote-pranswer state260. The WebRTC client may then perform ICE negotiations with the peer WebRTC client, including (per the techniques of this disclosure) providing QoS flow data to a server device executing an AF for the ICE candidates. The WebRTC client may then transition back to stable state256.

On the other hand, in stable state256, the WebRTC client may receive a remote offer from the peer WebRTC client. In response to receiving the remote offer (setRemote(OFFER)), the WebRTC client may transition to have-remote-offer state252. The remote offer may include SDP data representing supported CODECs, formatting, or the like for a new media communication session proposed by the peer WebRTC client. The WebRTC client may determine which of the offered elements are supported by the host client device executing the WebRTC client, and formulate a response. After sending the response to the peer WebRTC client (setLocal(PRANSWER)), the WebRTC client may transition to have-local-pranswer state254. Once again, the WebRTC client may perform ICE negotiation, including sending QoS flow data to the server executing the AF according to the techniques of this disclosure, then transition back to stable state256.

FIG.6is a flow diagram illustrating an example service280for creating a new application session context for managing a quality of service (QoS) flow. A network function (NF) service consumer282and a policy control function (PCF)284participate in service280. PCF284offers services to NF service consumer282, such as a proxy-call session control function (P-CSCF) or application functions (AFs), to request the allocation of QoS for a specific QoS flow that they manage. NF service consumer282(e.g., a WebRTC client or other application executed by a client device/UE) may send an HTTP POST message specifying one or more application sessions286to PCF284, and PCF284may respond with an HTTP201“created” success message to NF service consumer282. Service280may be used to create a new Application Session Context for the management of a QoS flow.

For real-time media, the Application Session Context may provide a per media component description of the QoS flow and the requested QoS parameters. The following table depicts a subset of the parameters that are included in the request.

A FlowDescription is provided for each media sub-component, which includes a 5-Tuple, that describes the QoS Flow accurately. For example, the 5-tuple may include a source IP address, source port, destination IP address, destination port, and protocol for a QoS Flow. The QoS requirements are indicated by component and include bandwidth, latency, and packet loss indications.

To request the application of a policy to a streaming session, the user equipment (UE) uses the Dynamic Policies API, that is exposed by the 5G Media Streaming (5GMS) application function (AF), to provide information about the session and requested QoS to the 5GMS AF. The Media Session Handler (MSH) in the UE gathers this information from the application. Certain example parameters that are included as part of the request to the 5GMS AF are shown in the following table:

The QoS information can be provided as a reference to a pre-defined QoS template that was set up during the provisioning step or as a set of QoS parameters.

FIG.7is a block diagram illustrating an example network300that may apply the techniques of this disclosure to establish a quality of service (QoS) flow for a media communication session between client devices. In particular, network function (NF) consumers, such as P-CSCFs or AFs, may be configured to apply these techniques to request QoS parameters and to define a QoS flow for a communication session between client devices (e.g., UEs). In the example ofFIG.7, network300includes user equipment (UE)302A,302B (UEs302), Traversal Using Relay Network Address Translation (NAT) (TURN) server308, and 5GMS AF306. UEs302may correspond to client devices110ofFIG.1, and 5GMS AF306may correspond to server device102ofFIG.1. In this example, UE302A also includes media session handler304.

5GMS AF306may offer TURN server308, a Session Traversal of UDP (STUN) server, and/or a multipoint control unit (MCU) (STUN server and MCU not shown in the example ofFIG.7) to user equipment (UE). In particular, 5GMS AF306may send information to MSH304as part of a Service Access Information API. This information can be passed as part of the configuration of the RTCPeerConnection to allow for proper interactive connectivity establishment (ICE) negotiation.

UE302A, in this example, may send an updateCandidate message to 5GMS AF306. UE302A may include a qosReference in the updateCandidate message. Including the qosReference in the updateCandidate message, when updating the QoS flow description upon successful ICE negotiation, may result in forming an association between a QoS Flow description and a QoS specification. UE302A may include the following information in the request:

Each time a new ICE candidate is identified, a notification is sent to the application. The application identifies the new QoS flows associated with this new candidate and decides whether to update the QoS association with the AF. If the ICE candidate type is a “relay,” this indicates that TURN server308will be deployed. In such case, 5GMS AF306will identify the corresponding QoS flows to the remote port/IP address pair and request QoS to be applied to it as well.

This is applicable to TURN servers, such as TURN server308, that are hosted in the trusted domain. TURN servers outside a mobile network operator (MNO) network are not subject to QoS allocation. A TURN server in the trusted domain, such as TURN server308, may be enhanced with the capability to send updates of the QoS flow description to 5GMS AF306directly. Alternatively, this can be done by a signaling server that is hosted by the MNO.

As TURN server308does not include information indicative of the location of 5GMS AF306, 5GMS AF306probes TURN server308to detect support for the 5G enhanced functionality. If TURN server308does support this enhanced functionality, it will respond with the actual mapping between the QoS flow to UE302A and the QoS flow to UE302B. 5GMS AF306can then subsequently apply the QoS specification to the second segment of the connection. The association may be established by providing the description of the QoS flow to UE302A.

FIG.8is a block diagram illustrating an example collaboration scenario in which the techniques of this disclosure may be used. The example ofFIG.8includes network320and mobile network operators (MNOs)330A,330B (MNOs330).

UEs336may include components similar to those of client device120ofFIG.2. UEs336may perform the techniques of this disclosure to initiate media communication session338. In this example, UEs336are coupled to different respective MNOs330. That is, UE336A is coupled to MNO330A and UE336B is coupled to MNO330B. UE336A may initiate media communication session338with UE336B. Initially, UE336A may send a STUN request to STUN server322to determine its own public IP address and port values. UE336A may then construct a list of ICE candidates representing the pairs of IP address and port values received from STUN server322. UE336A may then send the list of ICE candidates to UE336B.

In response, UE336B may request its public IP address and port values from STUN server322. UE336B may then generate a list of ICE candidates including pairs of IP address and port values for itself, and send this list of ICE candidates back to UE336A.

UE336A may receive the list of ICE candidates from UE336B and then validate the ICE candidates in the list. For example, UE336A may send a STUN request to each IP address and port of the ICE candidates and determine which STUN requests result in responses. For each IP address and port pair for which a response to the STUN request is received, UE336A may determine that the corresponding ICE candidate is valid. UE336B may similarly determine which of the ICE candidates received from UE336A are valid.

After determining the valid ICE candidates, UE336A may send data representing the valid ICE candidates and quality of service (QoS) flows to 5GMS AF332A. 5GMS AF332A may provide media control for media communication session338. Similarly, UE336B may send data representing the valid ICE candidates and QoS flows to 5GMS AF332B, which may additionally or alternatively provide media control for media communication session338. UEs336may negotiate a pair of valid IP ICE candidates for each of UE336A and UE336B to establish media communication session338. Furthermore, UEs336may determine an association between a QoS specification and the one of the QoS flows for the media communication session, and apply QoS to media communication session338according to the QoS specification.

The example ofFIG.8provides over-the-top (OTT) WebRTC with 5G support. WebRTC functions may be hosted by WebRTC signaling server326, which may be an application service provider. MNOs330may provide network assistance and QoS to UEs336. In particular, UEs336may execute respective WebRTC applications, which may pass information to respective MSHs of UEs336. The MSHs may use service based architecture (SBA) procedures to invoke the network assistance and QoS. In one alternative example, WebRTC signaling server326may communicate with PCF/SMF/NEFs334.

In general, the process performed by UEs356ofFIG.9may be substantially similar to those performed by UEs336ofFIG.8to establish and participate in media communication session362. In this example, however, MNOs350provide respective STUN servers358and TURN/MCU servers360, instead of the STUN and TURN/MCU servers being provided separately. Thus, in this example, WebRTC functions are provided by a trusted MNO, namely, MNOs350. MNOs350may provide WebRTC functions to customers, such as users of UEs356. The WebRTC applications executed by UEs356may discover STUN servers358and TURN/MCU servers360through respective MNOs350and include them in the ICE negotiation. STUN servers358and TURN/MCU servers360may extract information, such as a network 5-tuple (source IP address, destination IP address, source port, destination port, and protocol) and pass this information to 5GMS AFs352and/or PCF/SMF/NEFs354. STUN servers358and TURN/MCU servers360may be implemented as 5G application functions or 5G application servers, in various examples.

FIG.10is a block diagram illustrating another example collaboration scenario in which the techniques of this disclosure may be used. The example ofFIG.10depicts MNO370, which includes 5GMS AF372, PCF/SMF/NEF374, UEs376A,376B (UEs376), STUN server378, TURN/MCU server380, and WebRTC signaling server382.

In general, the process performed by UEs376ofFIG.10may be substantially similar to those performed by UEs336ofFIG.8to establish and participate in media communication session384. In this example, however, UEs376are each coupled to the same MNO, i.e., MNO370. Likewise, MNO370provides each of the various network components and services used for WebRTC in this example. That is, in this example, there are MNO-facilitated WebRTC services. MNO370may own or offer the WebRTC services on behalf of an application provider. This example may be used for split rendering when UEs376perform different parts of a rendering process, e.g., for XR, MR, AR, VR, or the like. This example may implement a standardized WebRTC signaling protocol.

In this example, WebRTC signaling server382may receive the SDP offer and provide an SDP answer. WebRTC signaling server382may extract media and 5-tuple information and pass this information to 5GMS AF372and/or PCF/SMF/NEF374. WebRTC signaling server382may be implemented as a 5G application function or a 5G application server in some examples.

FIG.11is a block diagram illustrating another example collaboration scenario in which the techniques of this disclosure may be used. The example ofFIG.11depicts MNOs390A,390B (MNOs390). Each of MNOs390includes respective WebRTC signaling servers402A,402B (WebRTC signaling servers402), 5GMS AFs392A,392B (5GMS AFs392), PCF/SMF/NEFs394A,394B (PCF/SMF/NEFs394), UEs396A,396B (UEs396), STUN servers398A,398B (STUN servers398), and TURN/MCU servers400A,400B (TURN/MCU servers400). In this example, UEs396A and396B perform techniques of this disclosure to establish media communication session404.

In general, the process performed by UEs396ofFIG.11may be substantially similar to those performed by UEs336ofFIG.8to establish and participate in media communication session404. In this example, however, MNOs390include respective WebRTC signaling servers402. In this manner, the example ofFIG.11provides interoperable WebRTC services. That is, the WebRTC services are MNO-facilitated and operate across MNOs390. WebRTC signaling servers402may use a standardized WebRTC signaling for IOP to establish a distributed session control protocol. In this example, WebRTC signaling servers402, STUN servers398, and TURN/MCU servers400may exchange session parameters across MNOs390.

The techniques of this disclosure may achieve certain advantages. For example, these techniques separate QoS specification from QoS flow definition, which may allow for separate ICE negotiation. Performance of these techniques may also extend the QoS specification to cover all segments of the connection. In particular, these techniques support requesting QoS for the case where a TURN server is hosted by the MNO. These techniques also allow for linkage between the QoS specification and the QoS flow descriptions.

FIG.12is a flowchart illustrating an example method for performing techniques of this disclosure. The method ofFIG.11is explained with respect to client device120ofFIG.2, although it should be understood that other devices, such as client devices110ofFIG.1, UEs302ofFIG.7, UEs336ofFIG.8, UEs356ofFIG.9, UEs376ofFIG.10, or UEs396ofFIG.11, may also be configured to perform this or a similar method.

Initially, client device120may determine a list of ICE candidates (420) for a peer client device with which to initiate a media communication session. For example, client device120may send a request to the peer client device and receive, in response to the request, a list of ICE candidates from the peer client device. The list of ICE candidates may include a list of pairs of IP addresses and ports by which the peer client device can be reached. Each of client device120and the peer client device may be connected to a network device that performs network address translation (NAT) to convert between the public IP address and a private IP address for a private network to which the client device is communicatively coupled, e.g., a network provided by a mobile network operator (MNO).

Client device120may then validate ICE candidates in the list of ICE candidates (422). For example, client device120may send STUN requests to each IP address and port in the list received from the peer client device, and determine that ICE candidates for which responses are received to the STUN requests are valid. Client device120may send data representing QoS flows for the valid ICE candidates to a 5GMS application function (AF), which may be executed by a server device forming part of the MNO or other private network to which client device120is connected (424).

Client device120may then determine one or more of the valid ICE candidates to use for the media communication session (426). For example, client device120may negotiate with the peer network device to determine respective pairs of IP addresses and ports for each of client device120and the peer client device for a particular media communication session. Client device120may then establish the media communication session (428). For example, client device120may perform the techniques discussed with respect toFIG.5to establish a particular media communication session, e.g., by sending an SDP offer to the peer client device and receiving an SDP answer from the peer client device, or by receiving an SDP offer from the peer client device and responding with an SDP answer to the peer client device.

Furthermore, client device120may determine a QoS specification and QoS flow for the media communication session (430). Client device120may provide data to an application function (e.g., application function104ofFIG.1) to cause the application function to apply QoS to the media communication session using the QoS specification (432) and the QoS flow associated with the determined ICE candidate for the media communication session. For example, client device102may invoke QoS provided by a mobile network operator (MNO) that operates server device102and application104ofFIG.1.

In this manner, the method ofFIG.11represents an example of a method including determining, by a first client device, a list of interactive connectivity establishment (ICE) candidates for a second client device; determining, by the first client device, valid ICE candidates in the list of ICE candidates for the second client device; for one or more of the valid ICE candidates, sending, by the first client device, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establishing, by the first client device, the media communication session with the second client device using the determined one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification and the one of the QoS flows for the media communication session; and providing, by the first client device, data to the AF to apply QoS to the media communication session according to the QoS specification.

Certain example techniques of this disclosure are summarized in the following clauses:

Clause 1: A method of applying quality of service to a media communication session, the method comprising: determining, by a first client device, a list of interactive connectivity establishment (ICE) candidates; sending, by the first client device, a media communication session request to a second client device, the media communication session request including data representing the list of ICE candidates; determining, by the first client device, valid ICE candidates in the list of one or more of the ICE candidates; for one or more of the valid ICE candidates, sending, by the first client device, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the communication session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification with the one of the QoS flows; and applying, by the first client device, QoS to the communication session according to the QoS specification.

Clause 2: The method of clause 1, further comprising receiving, from the server device executing the AF, data representing at least one of a Traversal Using Relay NAT (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 3: The method of any of clauses 1 and 2, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 4: The method of any of clauses 1-3, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 5: The method of any of clauses 1-4, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 6: The method of any of clauses 1-5, further comprising sending an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 12: A device for applying quality of service to a media communication session, the device comprising one or more means for performing the method of any of clauses 1-6.

Clause 13: The device of clause 12, wherein the one or more means comprise one or more processors implemented in circuitry.

Clause 14: The device of any of clauses 12 and 13, further comprising a display.

Clause 15: The device of any of clauses 12-14, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

Clause 16: The device of clause 12-15, further comprising a memory.

Clause 17: A computer-readable storage medium having stored thereon instructions that, when executed, cause a processor to perform the method of any of clauses 1-6.

Clause 18: A first client device for applying quality of service to a media communication session, the first client device comprising: means for determining a list of interactive connectivity establishment (ICE) candidates; means for sending a media communication session request to a second client device, the media communication session request including data representing the list of ICE candidates; means for determining valid ICE candidates in the list of ICE candidates; means for sending, for one or more of the valid ICE candidates, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; means for determining an association between a QoS specification with the one of the QoS flows; and means for applying QoS to the communication session according to the QoS specification.

Clause 19: A method of applying quality of service to a media communication session, the method comprising: determining, by a first client device, a list of interactive connectivity establishment (ICE) candidates for a second client device; determining, by the first client device, valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, sending, by the first client device, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establishing, by the first client device, the media communication session with the second client device using the determined one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification and the one of the QoS flows for the media communication session; and providing, by the first client device, data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 20: The method of clause 19, wherein determining the list of ICE candidates comprises: receiving data defining a plurality of ICE candidates; and forming the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 21: The method of clause 19, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and providing the data to the application function to apply QoS to the media communication session comprises invoking QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 22: The method of clause 19, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and determining the list of ICE candidates comprises receiving data representing one or more of the ICE candidates from the first MNO.

Clause 23: The method of clause 19, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 24: The method of clause 19, further comprising receiving, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 25: The method of clause 19, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 26: The method of clause 19, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 27: The method of clause 19, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 28: The method of clause 19, further comprising sending an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 29: The method of clause 19, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 30: A first client device for applying quality of service to a media communication session, the first client device comprising: a memory configured to store media data; and one or more processors implemented in circuitry and configured to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 31: The first client device of clause 30, wherein to determine the list of ICE candidates, the one or more processors are configured to: receive data defining a plurality of ICE candidates; and form the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 32: The first client device of clause 30, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and to provide data to the application function to apply QoS to the media communication session, the one or more processors are configured to invoke QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 33: The first client device of clause 30, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and to determine the list of ICE candidates, the one or more processors are configured to receive data representing one or more of the ICE candidates from the first MNO.

Clause 34: The first client device of clause 30, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 35: The first client device of clause 30, wherein the one or more processors are further configured to receive, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 36: The first client device of clause 30, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 37: The first client device of clause 30, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 38: The first client device of clause 30, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 39: The first client device of clause 30, wherein the one or more processors are further configured to send an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 40: The first client device of clause 30, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 41: The first client device of clause 30, further comprising a display.

Clause 42: The first client device of clause 30, wherein the first client device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

Clause 43: A computer-readable storage medium having stored thereon instructions that, when executed, cause a processor of a first client device to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 44: The computer-readable storage medium of clause 43, wherein the instructions that cause the processor to determine the list of ICE candidates comprise instructions that cause the processor to: receive data defining a plurality of ICE candidates; and form the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 45: The computer-readable storage medium of clause 43, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the instructions that cause the processor to provide data to the application function to apply QoS to the media communication session comprise instructions that cause the processor to invoke QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 46: The computer-readable storage medium of clause 43, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the instructions that cause the processor to determine the list of ICE candidates comprise instructions that cause the processor to receive data representing one or more of the ICE candidates from the first MNO.

Clause 47: The computer-readable storage medium of clause 43, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 48: The computer-readable storage medium of clause 43, further comprising instructions that cause the processor to receive, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 49: The computer-readable storage medium of clause 43, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 50: The computer-readable storage medium of clause 43, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 51: The computer-readable storage medium of clause 43, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 52: The computer-readable storage medium of clause 43, further comprising instructions that cause the processor to send an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 53: The computer-readable storage medium of clause 43, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 54: A first client device for applying quality of service to a media communication session, the first client device comprising: means for determining a list of interactive connectivity establishment (ICE) candidates for a second client device; means for determining valid ICE candidates in the list of ICE candidates; means for sending, for one or more of the valid ICE candidates, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; means for establishing the media communication session with the second client device using the determined one of the valid ICE candidates; means for determining an association between a QoS specification and the one of the QoS flows for the media communication session; and means for providing data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 55: A method of applying quality of service to a media communication session, the method comprising: determining, by a first client device, a list of interactive connectivity establishment (ICE) candidates for a second client device; determining, by the first client device, valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, sending, by the first client device, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establishing, by the first client device, the media communication session with the second client device using the determined one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification and the one of the QoS flows for the media communication session; and providing, by the first client device, data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 56: The method of clause 55, wherein determining the list of ICE candidates comprises: receiving data defining a plurality of ICE candidates; and forming the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 57: The method of any of clauses 55 and 56, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and providing the data to the application function to apply QoS to the media communication session comprises invoking QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 58: The method of any of clauses 55 and 56, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and determining the list of ICE candidates comprises receiving data representing one or more of the ICE candidates from the first MNO.

Clause 59: The method of any of clauses 55 and 56, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 60: The method of any of clauses 55-59, further comprising receiving, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 61: The method of any of clauses 55-60, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 62: The method of any of clauses 55-61, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 63: The method of any of clauses 55-62, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 64: The method of any of clauses 55-63, further comprising sending an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 65: The method of any of clauses 55-64, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 66: A first client device for applying quality of service to a media communication session, the first client device comprising: a memory configured to store media data; and one or more processors implemented in circuitry and configured to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 67: The first client device of clause 66, wherein to determine the list of ICE candidates, the one or more processors are configured to: receive data defining a plurality of ICE candidates; and form the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 68: The first client device of any of clauses 66 and 67, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and to provide the data to the application function to apply QoS to the media communication session, the one or more processors are configured to invoke QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 69: The first client device of any of clauses 66 and 67, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and to determine the list of ICE candidates, the one or more processors are configured to receive data representing one or more of the ICE candidates from the first MNO.

Clause 70: The first client device of any of clauses 66 and 67, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 71: The first client device of any of clauses 66-70, wherein the one or more processors are further configured to receive, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 72: The first client device of any of clauses 66-71, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 73: The first client device of any of clauses 66-72, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 74: The first client device of any of clauses 66-73, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 75: The first client device of any of clauses 66-74, wherein the one or more processors are further configured to send an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 76: The first client device of any of clauses 66-75, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 77: The first client device of any of clauses 66-76, further comprising a display.

Clause 78: The first client device of any of clauses 66-77, wherein the first client device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

Clause 79: A computer-readable storage medium having stored thereon instructions that, when executed, cause a processor of a first client device to: determine a list of interactive connectivity establishment (ICE) candidates for a second client device; determine valid ICE candidates in the list of ICE candidates; for one or more of the valid ICE candidates, send data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; determine one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; establish the media communication session with the second client device using the determined one of the valid ICE candidates; determine an association between a QoS specification and the one of the QoS flows for the media communication session; and provide data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 80: The computer-readable storage medium of clause 79, wherein the instructions that cause the processor to determine the list of ICE candidates comprise instructions that cause the processor to: receive data defining a plurality of ICE candidates; and form the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 81: The computer-readable storage medium of any of clauses 79 and 80, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the instructions that cause the processor to provide the data to the application function to apply QoS to the media communication session comprise instructions that cause the processor to invoke QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 82: The computer-readable storage medium of any of clauses 79 and 80, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the instructions that cause the processor to determine the list of ICE candidates comprise instructions that cause the processor to receive data representing one or more of the ICE candidates from the first MNO.

Clause 83: The computer-readable storage medium of any of clauses 79 and 80, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 84: The computer-readable storage medium of any of clauses 79-83, further comprising instructions that cause the processor to receive, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 85: The computer-readable storage medium of any of clauses 79-84, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 86: The computer-readable storage medium of any of clauses 79-85, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 87: The computer-readable storage medium of any of clauses 79-86, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 88: The computer-readable storage medium of any of clauses 79-87, further comprising instructions that cause the processor to send an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 89: The computer-readable storage medium of any of clauses 79-88, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 90: A first client device for applying quality of service to a media communication session, the first client device comprising: means for determining a list of interactive connectivity establishment (ICE) candidates for a second client device; means for determining valid ICE candidates in the list of ICE candidates; means for sending, for one or more of the valid ICE candidates, data representing quality of service (QoS) flows associated with the one or more of the valid ICE candidates to a server device executing an application function (AF), the AF providing media control for the media communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with the one of the valid ICE candidates; means for establishing the media communication session with the second client device using the determined one of the valid ICE candidates; means for determining an association between a QoS specification and the one of the QoS flows for the media communication session; and means for providing data to the AF to apply QoS to the media communication session according to the QoS specification.

Clause 91: The first client device of clause 90, wherein the means for determining the list of ICE candidates comprises: means for receiving data defining a plurality of ICE candidates; and means for forming the list of ICE candidates to include one or more of the plurality of ICE candidates.

Clause 92: The first client device of any of clauses 90 and 91, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the means for providing the data to the application function to apply QoS to the media communication session comprises means for invoking QoS provided by the first MNO using a service based architecture (SBA) procedure offered by the first MNO.

Clause 93: The first client device of any of clauses 90 and 91, wherein the first client device is communicatively coupled to a first mobile network operator (MNO), the second client device is communicatively coupled to a second MNO, and the means for determining the list of ICE candidates comprises means for receiving data representing one or more of the ICE candidates from the first MNO.

Clause 94: The first client device of any of clauses 90 and 91, wherein the first client device is communicatively coupled to a mobile network operator (MNO) and the second client device is communicatively coupled to the MNO.

Clause 95: The first client device of any of clauses 90-94, further comprising means for receiving, from the server device executing the AF, data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

Clause 96: The first client device of any of clauses 90-95, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data representing associations between QoS flow descriptions and QoS specifications.

Clause 97: The first client device of any of clauses 90-96, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes data describing a service data flow for which QoS is provided.

Clause 98: The first client device of any of clauses 90-97, wherein the data representing the QoS flows associated with the one or more of the valid ICE candidates includes a reference to the QoS specification.

Clause 99: The first client device of any of clauses 90-98, further comprising means for sending an update message to the server device executing the AF including data associating one of the valid ICE candidates with one of the QoS flows.

Clause 100: The first client device of any of clauses 90-99, wherein the media communication session comprises a Web Real-Time Communication (WebRTC) communication session.

Clause 101: A method of applying quality of service to a media communication session, the method comprising: receiving, from a first client device and by a server device executing an application function (AF), data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device, the AF providing media control for a media communication session between the first client device and a second client device; receiving, from the first client device and by the server device, data representing an association between one of the QoS flows and an associated QoS specification; and applying, by the server device, QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

Clause 102: A server device for applying quality of service to a media communication session, the device comprising: a memory configured to store associations between quality of service (QoS) flows and one or more valid interactive connectivity establishment (ICE) candidates for a first client device; and one or more processors implemented in circuitry and configured to: execute an application function (AF), the AF providing media control for a media communication session between the first client device and a second client device; receive, from the first client device, data representing the associations between QoS flows and the one or more valid ICE candidates for the first client device; receive, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and apply, by the server device, QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

Clause 103: A computer-readable storage medium having stored thereon instructions that cause a processor of a server device to: executing an application function (AF), the AF providing media control for a media communication session between a first client device and a second client device; receive, from the first client device, data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device; receive, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and apply QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

Clause 104: A server device for applying quality of service to a media communication session, the server device comprising: means for executing an application function (AF), the AF providing media control for a media communication session between a first client device and a second client device; means for receiving, from the first client device, data representing quality of service (QoS) flows associated with one or more valid interactive connectivity establishment (ICE) candidates for the first client device; means for receiving, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; and means for applying QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows.

Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” and “processing circuitry,” as used herein may refer to any of the foregoing structures or any other structure suitable for implementation of the techniques described herein. Also, the techniques could be fully implemented in one or more circuits or logic elements.