Supporting quality of service for media communications

Abstract

A client device (e.g., User Equipment or "UE") may be configured to engage in a media communication session, e.g., a WebRTC session, with another client device. The client device may separate the Quality of Service (QoS) specification from the QoS flow definition to allow for a separate Interactive Connectivity Establishment (ICE) negotiation. The QoS specification may cover all segments of the connection for the media communication session. For example, QoS may be required when 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.

Description

[Technical field]

[0001]

[0001] This application claims priority to U.S. Patent Application No. 17 / 818,566, filed August 9, 2022, and U.S. Provisional Patent Application No. 63 / 232,005, filed August 11, 2021, the entire contents of which are incorporated herein by reference. U.S. Patent Application No. 17 / 818,566, filed August 9, 2022, claims the benefit of U.S. Provisional Patent Application No. 63 / 232,005, filed August 11, 2021.

[0002] This disclosure relates to the transmission of media data in real time over computer networks. [Background technology]

[0003]

[0003] Client devices, also referred to as "user equipment" or "UE", can be configured to exchange audio and / or video data with each other over a computer network. The network can include, for example, routers, hubs, bridges, switches, servers, security devices, etc., to transport data between the client devices. The client devices may be smartphones, tablets, personal computers, laptops, etc. The exchange of audio and / or video data between the client devices can be performed in real time, for example as a voice or video call. Summary of the Invention

[0004]

[0004] In general, the present disclosure describes techniques for applying quality of service (QoS) to media communications between client devices. For example, QoS can be applied to a Web Real-Time Communication (WebRTC) session between two client devices. The techniques of the present disclosure can include separating the QoS specification from the QoS flow definition, which allows for a separate interactive connectivity establishment (ICE) negotiation. The QoS specification can cover all segments of the connection for the media communication session. For example, QoS may be required when 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.

[0005]

[0005] In one example, a method for applying quality of service to a media communication session includes determining, by a first client device, a list of bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device executing an application function (AF) that provides 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 one of the valid ICE candidates; establishing, by the first client device, a 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 one of the QoS flows for the media communication session; and providing, by the first client device, data to the application function for applying QoS to the media communication session in accordance with the QoS specification.

[0006]

[0006] 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 configured to: determine a list of bidirectional connectivity establishment (ICE) candidates for a second client device, determine valid ICE candidates in the list of ICE candidates, and for one or more of the valid ICE candidates, send data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device executing an application function (AF) that provides media control for the media communication session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a 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 one of the QoS flows for the media communication session, and provide data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0007]

[0007] In another example, a computer-readable storage medium stores instructions that, when executed, cause a processor of a first client device to determine a list of bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device executing an application function (AF) that provides media control for the media communications session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a media communications session with the second client device using the determined one of the valid ICE candidates, determine an association between a QoS specification and one of the QoS flows for the media communications session, and provide data to the AF for applying QoS to the media communications session in accordance with the QoS specification.

[0008]

[0008] In another example, a first client device for applying quality of service to a media communication session comprises means for determining a list of bidirectional 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 one or more of the valid ICE candidates to a server device executing an application function (AF) that provides media control for the media communication session, means for determining one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, means for establishing a 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 one of the QoS flows for the media communication session, and means for providing data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0009]

[0009] In another example, a method for applying quality of service to a media communication session includes receiving, by a server device executing an application function (AF) providing media control for a media communication session between a first client device and a second client device, data from the first client device representing quality of service (QoS) flows associated with one or more valid bidirectional connectivity establishment (ICE) candidates for the first client device, receiving, by the server device, data from the first client device 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0010]

[0010] In another example, a server device for applying quality of service to a media communication session includes a memory configured to store an association between quality of service (QoS) flows and one or more valid bidirectional connectivity establishment (ICE) candidates for a first client device, and one or more processors implemented in circuitry configured to execute an application function (AF) that provides 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 an association between the QoS flows and 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0011]

[0011] In another example, a computer-readable storage medium stores instructions that cause a processor of a server device to execute an application function (AF) that provides 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 bidirectional 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0012]

[0012] In another example, a server device for applying quality of service to a media communication session includes means for executing an application function (AF) that provides 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 bidirectional 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0013] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will become apparent from the description, drawings, and claims. [Brief description of the drawings]

[0014] [Figure 1]

[0014] FIG. 1 is a block diagram illustrating an example network in which client devices exchange media data with each other. [Diagram 2]

[0015] FIG. 2 is a block diagram illustrating an example client device in accordance with techniques of this disclosure. [Diagram 3]

[0016] FIG. 1 is a block diagram illustrating an example Web Real-Time Communications (WebRTC) application programming interface (API) architecture. [Figure 4]

[0017] FIG. 1 is a conceptual diagram illustrating an example WebRTC protocol stack. [Diagram 5]

[0018] 2 is a state diagram illustrating an example process 250 for initiating a media communication session via WebRTC. [Figure 6]

[0019] 1 is a flow diagram illustrating an example process for creating a new application session context for managing Quality of Service (QoS) flows. [Figure 7]

[0020] FIG. 1 is a block diagram illustrating an example network in which the techniques of this disclosure can be applied to establish quality of service (QoS) flows for media communication sessions between client devices. [Figure 8]

[0021] FIG. 1 is a block diagram illustrating an example collaborative scenario in which techniques of this disclosure may be used. [Figure 9]

[0022] FIG. 2 is a block diagram illustrating another example collaborative scenario in which techniques of this disclosure may be used. [Figure 10]

[0023] FIG. 2 is a block diagram illustrating another example collaborative scenario in which techniques of this disclosure may be used. [Figure 11]

[0024] FIG. 2 is a block diagram illustrating another example collaborative scenario in which techniques of this disclosure may be used. [Figure 12]

[0025] 1 is a flowchart illustrating an example method for implementing techniques of this disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015]

[0026] 1 is a block diagram illustrating an example network 100 in which client devices 110A, 110B (client devices 110) exchange media data with each other. In this example, network 100 includes client devices 110 and a server device 102. Server device 102 includes an application server 106 and executes application functions 104. In general, application functions 104 provide media control and application server 106 provides, for example, media content traffic for communication sessions 114 between client devices 110.

[0016]

[0027] Client device 110 includes respective agents 112A, 112B (agents 112). Agents 112 may represent Web Real-Time Communications (WebRTC) agents. Agents 112 may include respective WebRTC application programming interfaces (APIs). In general, WebRTC represents a set of APIs and protocols for real-time communication, e.g., for communication session 114. For example, client device 110A may use agent 112A to conduct communication session 114 with client device 110B via WebRTC APIs and protocols.

[0017]

[0028] Client device 110A may first generate a request, such as a Session Description Protocol (SDP) offer. For example, client device 110A may invoke "createOffer" on an RTCPeerConnection object via agent 112A. The SDP offer may include information about agent 112A, such as supported encoders / decoders, whether the communication session 114 will include audio and / or video, and other connection-related information. In addition, the SDP offer may include a list of one or more Bidirectional Connectivity Establishment (ICE) candidates, including port and IP pairs that client device 110B can use to establish the communication session 114 with client device 110A.

[0018]

[0029] To build a list of ICE candidates, client device 110A may send one or more requests to a Session Traversal of UDP (STUN) server, such as server device 102. The STUN server may provide client device 110A with a public port and IP address for client device 110A. Client device 110A may then add each port / IP address pair to the list of ICE candidates. After building the list of ICE candidates, client device 110A may send an SDP offer to client device 110B over a signaling channel between agents 112A and 112B, for example, using WebRTC.

[0019]

[0030] After receiving the SDP offer, client device 110B can generate an SDP answer. Client device 110B can collect a list of ICE candidates for itself, generate an SDP answer to include the list of ICE candidates, and then send the SDP answer to client device 110A. The client devices 110 can then check various port / IP address pairs from the lists received from each other and send a STUN request to each pair. If a response is received from the other of the client devices 110, the one of the client devices 110 that sent the response can determine that the corresponding port and IP pair for that request is a valid ICE candidate.

[0020]

[0031] After the client device 110 finishes testing the port / IP pairs, the client device 110 can determine which of the valid pairs to use. The client device 110 can then exchange media data via the selected valid pair.

[0021]

[0032] Additionally, the server device 102 may request quality of service (QoS) data from the client devices 110A, 110B for the communication session 114. In accordance with the techniques of this disclosure, the server device 102 may submit a QoS request to request QoS reference data after an ICE negotiation between the client devices 110. The QoS request may include data associating a QoS flow description with a QoS specification, data describing the service data flow for which the requested QoS is to be provided, and data representing a reference to the QoS specification.

[0022]

[0033] After one of the client devices 110, e.g., client device 110A, identifies a valid ICE candidate, client device 110A may determine whether to associate a new QoS flow associated with the ICE candidate and update the QoS association with server device 102 (specifically, application function 104). In response, server device 102 may also determine whether to identify a corresponding QoS flow to the remote pair and request that QoS be applied to it.

[0023]

[0034] 2 is a block diagram illustrating an example client device 120 in accordance with techniques of this disclosure. In this example, client device 120 includes a user interface 122, a 5G Media Streaming (5GMS)-aware application 124, a media session handler (MSH) 126, an access client 128, an agent 130, a network interface 136, a memory 140, a decoder 132, a renderer 134, a display 136, and a speaker 138.

[0024]

[0035] The user interface 122 can represent a variety of user interfaces, such as a touch screen, buttons, joysticks, peripherals such as microphones, cameras, earphones, external microphones, external cameras, game controllers, keyboards, mice, etc. In general, the user interface 122 allows a user of the client device 120 to interact with the client device 120 and provide input. For example, a user can use the client device 120 to participate 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 a WebRTC session, a user can 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, etc.

[0025]

[0036] The user interface 122 may pass received media data for a media communication session to the encoder 142 for encoding. The encoder 142 may include an audio encoder, an image encoder, a video encoder, or other such encoder for encoding the media data for network transmission. The encoder 142 may provide the encoded media data to the 5G MS-aware application 124.

[0026]

[0037] The 5GMSd-aware application 124 may receive user input data from the user interface 122 and / or encoded media data from the encoder 142. The 5GMS-aware application 124 may pass information representing the user input data and the encoded media data to the MSH 126, which may also receive information from a 5GMS Application Function (AF) executed by a separate server device (not shown in FIG. 2), such as the AF 104 of FIG. 1.

[0027]

[0038] The MSH 126 may provide information to an access client 128, which may also receive one or more media streams from a 5G MS application server (AS) executed by a separate server device (not shown in FIG. 2), such as the AS 106 of FIG. 1.

[0028]

[0039] The access client 128 may initialize a media communication session, such as a WebRTC session, as discussed below. In accordance with 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 precise user location information is required, the amount of bandwidth required for the media communication session, etc. The access client 128 may receive media data for the media communication session and provide the media data to the decoder 132. The media data may also be stored (e.g., buffered) in the memory 140. The memory 140 may also store instructions to be executed by one or more processors, e.g., software or firmware instructions for any of the various components of the client device 120, such as the 5GMS-aware application 124, the MSH 126, the access client 128, the agent 130, the decoder 132, and / or the renderer 134.

[0029]

[0040] Agent 130 may correspond to one of agents 112 of FIG. 1. Agent 130 may represent a WebRTC agent that functions as a set of APIs and protocols for real-time communication for a media communication session. As discussed above, agent 130 may build a list of bidirectional connectivity establishment (ICE) candidates. Agent 130 may send and receive data via network interface 136, which may represent a wireless or wired network interface, such as a WiFi interface, an 802.11 interface, an Ethernet interface, etc.

[0030]

[0041] Agent 130 may determine a list of ICE candidates for another client device as well as for itself. For example, agent 130 may query a STUN server to determine its various public IP addresses and ports. Agent 130 may then form a list of ICE candidates to include one or more of the ICE candidates indicated in the data received from the STUN server. Agent 130 may further receive data representing one or more STUN and / or TURN servers before querying the STUN and / or TURN servers. In some examples, server device 102 may execute AF 104 to function as both a STUN server and a TURN server.

[0031]

[0042] Agent 130 may use the TURN server to establish a media communication session with another client device. For example, agent 130 of client device 120 may send an invitation to the other client device and receive an acceptance in response to the invitation. The invitation may include a list of ICE candidates for client device 120, 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.

[0032]

[0043] Agent 130 may then validate each ICE candidate in the list for the other client device. For example, agent 130 may send a STUN request to the IP address and port of a particular ICE candidate for the other client device. If a response to the STUN request is received, agent 130 may determine that the corresponding ICE candidate is valid. After determining the valid ICE candidates, agent 130 may negotiate with the other client devices to determine which ICE candidate should be used for the media communication session for each device.

[0033]

[0044] In accordance with the techniques of this disclosure, agent 130 can assign one or more quality of service (QoS) flows associated with each valid ICE candidate to server device 102 (FIG. 1). Server device 102 can then use this information to determine an appropriate QoS flow for a particular one of the ICE candidates. In this manner, data sent to other client devices as part of a media communication session, i.e., data destined for a public IP address and port for the other client device, can be sent via the corresponding QoS flow. In this manner, QoS can be applied to the media communication session.

[0034]

[0045] The decoder 132 may include an audio decoder, a video decoder, etc. The decoder 132 may receive media data exchanged via a media communication session and may decode the received media data. The decoder 132 may provide the decoded media data to a renderer 134, which may render the media data. For example, the renderer 134 may compose together various portions of the separately decoded media data for simultaneous playback and provide rendered image or video data to a display 136 and provide rendered audio data to a speaker 138.

[0035]

[0046] Thus, client device 120 represents 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 configured to: determine a list of bidirectional connectivity establishment (ICE) candidates for a second client device, determine valid ICE candidates in the list of ICE candidates, and, for one or more of the valid ICE candidates, send data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device executing an application function (AF) that provides media control for the media communication session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a 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 one of the QoS flows for the media communication session, and provide the data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0036]

[0047] Figure 3 is a block diagram illustrating an example Web real-time communications (WebRTC) architecture 156. Agent 112 of Figure 1 and agent 130 of Figure 2 may include components similar to those shown in WebRTC architecture 156 of Figure 3. WebRTC architecture 156 forms part of a system 150 for implementing WebRTC.

[0037]

[0048] In this example, the WebRTC architecture 156 includes a WebRTC application programming interface (API) 158 and a set of protocols that enable real-time communication. The WebRTC protocols allow any two WebRTC agents to negotiate and set up a bidirectional, secure real-time communication channel. The WebRTC API 156, in one example, exposes a JavaScript®-based API to enable development of applications that leverage the existing multimedia capabilities of client devices to establish real-time communication sessions. JavaScript is one example, and access to the WebRTC set of protocols is possible via other programming languages ​​as well.

[0038]

[0049] The Internet Engineering Task Force (IETF) RTCWeb group developed and maintains the WebRTC protocol. The Worldwide Web Consortium (W3C) develops the WebRTC API.

[0039]

[0050] As shown in FIG. 3, the WebRTC API 158 can be decomposed into three layers: a first layer containing APIs for web developers, including MediaStream, RTCPeerConnection, and RTCDataChannel objects; a second layer containing APIs for web browsers and user agent implementers and providers; and a third layer containing overridable APIs for audio / video capture and rendering and network input / output into which browser implementers can hook their implementations.

[0040]

[0051] 3, the system 150 includes a web application programming interface (API) 154 and a WebRTC architecture 156. The Web API 154 receives data from one or more web applications 152A-152N (web applications 152). The Web API 154 may provide data from the web applications 152 to the WebRTC architecture 156. The WebRTC architecture 156 in this example includes a WebRTC API 158, a session management and abstract signaling unit 160, a voice engine 170, a video engine 180, a transport unit 190, an audio capture 162, a video capture 164, and a network input / output (I / O) 166.

[0041]

[0052] The voice engine 170 includes an encoder / decoder (CODEC) 172, a jitter buffer 174, and an enhancement engine 176. The codec 172 may include, for example, an Internet Speech Audio Codec (iSAC) and / or an Internet Low Bitrate Codec (iLBC). The jitter buffer 174 may include both a jitter buffer and an error concealment unit. In some examples, the jitter buffer 174 may correspond to a NetEQ implementation of a jitter buffer. The enhancement engine 176 may include an echo cancellation unit and / or a noise reduction unit.

[0042]

[0053] The video engine 180 includes a CODEC 182, a jitter buffer 184, and an enhancement engine 186. The CODEC 182 may conform to one or more of various 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, ​​etc. The jitter buffer 184 buffers received video data until the video data is ready to be decoded. The enhancement engine 186 can enhance the decoded video data as post-loop processing, for example, using interpolation to upsample images to a higher display resolution, frame rate up-conversion (FRUC), post-loop filtering (e.g., artificial intelligence-based filtering), etc.

[0043]

[0054] The transport unit 190 includes a protocol 192, a multiplexing unit 194, and a peer-to-peer (P2P) STUN / TURN / ICE unit 196. The protocol 192 may include one or more of various transport protocols, such as Real-time Transport Protocol (RTP), Secure RTP (SRTP), etc. The multiplexing unit 194 may multiplex various streams together, such as one or more audio streams, one or more video streams, and other media (e.g., timed text / closed captions). The PTP STUN / TURN / ICE unit 196 generally issues STUN and / or TURN requests as part of an ICE negotiation to establish a P2P connection with another client device. The P2P STUN / TURN / ICE unit 196 may also implement the techniques of this disclosure to include QoS flow data with ICE candidates, for example, when sending the ICE candidate data to a server device that performs AF, so that the server device can associate the ICE candidates with appropriate QoS flows.

[0044]

[0055] The audio capture 162 may be a microphone for capturing a user's voice or other sound data. The video capture 164 may include one or more cameras for capturing image or video data. The network I / O unit 166 may include one or more network interfaces, such as wired or wireless interfaces, e.g., an 802.11 interface, a WiFi interface, an Ethernet interface, etc.

[0045]

[0056] 4 is a conceptual diagram illustrating an example WebRTC protocol stack 200. The WebRTC stack 200 includes components such as an audio engine, a video engine, and a transport component. The transport component provides a secure transport channel for both parties (e.g., client device 110 of FIG. 1) to communicate. The transport component can use a Real-time Transport Protocol (RTP) stack that operates over Datagram Transport Layer Security (DTLS) and leverages the Secure Real-time Transport Protocol (SRTP) profile.

[0046]

[0057] In the example of FIG. 4, the WebRTC stack 200 includes a media path component 202 and a signaling path component 204. The media path component 202 includes a time-critical component 206 and a non-time-critical component 208. The time-critical components include a CODEC 210, a SRTP 212, and a Secure RTP Control Protocol (SRTCP) 214. The non-time-critical components include a Stream Control Transmission Protocol (SCTP) 216. A Datagram Transport Layer Security (DTLS) protocol 218 supports each of the various media path components above the DTLS protocol 218 in the protocol stack. Similarly, an ICE / STUN / TURN protocol 220 supports the various components above the ICE / STUN / TURN protocol 220 in the stack. Data for each of the media path components 202 may be encapsulated according to a User Datagram Protocol (UDP) 222 and may be encapsulated and transported according to an Internet Protocol (IP) 224. The IP 224 may be IPv4, IPv6, or other IP layer protocol.

[0047]

[0058] The signaling path components 204 in this example include Session Initiation Protocol (SIP) 226, Short Message Peer-to-Peer (SMPP) protocol 228, Session Description Protocol 232, and other protocols 230. These protocols may use WebSockets 234, Server Sent Events (SSE), XML HTTP Request (XHR) 238, and other such services 240. These various services may run on top of HyperText Transfer Protocol (HTTP) 242. HTTP 242 may run on top of Transport Layer Security (TLS) protocol 244 to provide security, e.g., encryption. TLS-secured HTTP data may be transported according to Transmission Control Protocol (TCP) 246, which may be transported according to IP 224.

[0048]

[0059] 5 is a state diagram illustrating an example process 250 for initiating a media communication session via WebRTC. Once a WebRTC session is initiated, the WebRTC client may begin in a steady state 256. In the steady state 256, it is assumed that there is no offer and answer exchange currently in progress. To initiate each media communication session (e.g., an audio or video communication session), the WebRTC client may send or receive an offer representing SDP data including, for example, supported CODECs, formatting, etc.

[0049]

[0060] In the stable state 256, the WebRTC client may receive a local offer from a local element of the client device that includes the WebRTC client. In response to receiving the local offer (setLocal(OFFER)), the WebRTC client may transition to a have-local-offer state 258. The WebRTC client may then send an 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 a have-remote-pranswer state 260. The WebRTC client may then conduct ICE negotiation with the peer WebRTC client, including providing QoS flow data to a server device that performs AF for the ICE candidate (in accordance with the techniques of this disclosure). The WebRTC client may then transition back to the stable state 256.

[0050]

[0061] Meanwhile, in the stable state 256, the WebRTC client can receive a remote offer from a peer WebRTC client. In response to receiving the remote offer (setRemote(OFFER)), the WebRTC client can transition to a have-remote-offer state 252. The remote offer may include SDP data representing supported CODECs, formatting, etc., for the new media communication session proposed by the peer WebRTC client. The WebRTC client can determine which of the offered elements are supported by the host client device running the WebRTC client and formulate a response. After sending the response to the peer WebRTC client (setLocal(PRANSWER)), the WebRTC client can transition to a have-local-pranswer state 254. Again, the WebRTC client can conduct ICE negotiation, including sending QoS flow data to a server running AF according to the techniques of this disclosure, and then transition back to the stable state 256.

[0051]

[0062] FIG. 6 is a flow diagram illustrating an example service 280 for creating a new application session context for managing a quality of service (QoS) flow. A network function (NF) service consumer 282 and a policy control function (PCF) 284 participate in the service 280. The PCF 284 provides services to the NF service consumer 282, such as a proxy call session control function (P-CSCF) or an application function (AF), to request QoS allocation for specific QoS flows that they manage. The NF service consumer 282 (e.g., a WebRTC client or other application executed by the client device / UE) may send an HTTP POST message specifying one or more application sessions 286 to the PCF 284, which may respond with an HTTP 201 “create” success message to the NF service consumer 282. Using the service 280, a new application session context for management of the QoS flow may be created.

[0052]

[0063] For real-time media, the Application Session Context can provide a per-media-component description of the QoS flow and the requested QoS parameters. The following table shows a subset of the parameters included in the request.

[0053]

[0064] For each media subcomponent, a FlowDescription is provided that contains a 5-tuple that precisely describes the QoS flow. For example, the 5-tuple may contain the source IP address, source port, destination IP address, destination port, and protocol for the QoS flow. The QoS requirements are indicated by the component and include bandwidth, latency, and packet loss metrics.

[0054] [Table 1-1]

[0055] [Table 1-2]

[0056]

[0065] To request application of a policy to a streaming session, the user equipment (UE) provides information about the session and the requested QoS to the 5G Media Streaming (5GMS) Application Function (AF) using a Dynamic Policy API exposed by the 5GMS AF. A Media Session Handler (MSH) in the UE collects this information from the application. Some example parameters included as part of the request to the 5GMS AF are shown in the table below.

[0057] [Table 2]

[0058]

[0066] The QoS information may be provided as a reference to a predefined QoS template configured during the provisioning step, or as a set of QoS parameters.

[0059]

[0067] FIG. 7 is a block diagram illustrating an example network in which techniques of the present disclosure can be applied 300 to establish quality of service (QoS) flows for media communication sessions between client devices. In particular, a network function (NF) consumer, such as a P-CSCF or an AF, can be configured to apply these techniques to request QoS parameters and define QoS flows for communication sessions between client devices (e.g., UEs). In the example of FIG. 7, the network 300 includes user equipment (UE) 302A, 302B (UE 302), a traversal using relay network address translation (NAT) (TURN) server 308, and a 5GMS AF 306. The UE 302 can correspond to the client device 110 of FIG. 1, and the 5GMS AF 306 can correspond to the server device 102 of FIG. 1. In this example, the UE 302A also includes a media session handler 304.

[0060]

[0068] The 5GMS AF 306 may provide a TURN server 308, a Session Traversal of UDP (STUN) server, and / or a multipoint control unit (MCU) to the user equipment (UE) (STUN server and MCU are not shown in the example of FIG. 7). Specifically, the 5GMS AF 306 may send information to the MSH 304 as part of the Service Access Information API. This information is passed as part of the configuration of the RTCPeerConnection to enable proper Bidirectional Connectivity Establishment (ICE) negotiation.

[0061]

[0069] The UE 302A, in this example, may send an updateCandidate message to the 5GMS AF 306. The UE 302A may include a qosReference in the updateCandidate message. If the ICE negotiation is successful, including a qosReference in the updateCandidate message when updating the QoS flow description may result in an association being formed between the QoS flow description and the QoS specification. The UE 302A may include the following information in the request:

[0062] [Table 3]

[0063]

[0070] Each time a new ICE candidate is identified, a notification is sent to the application. The application will identify the new QoS flows associated with this new candidate and decide whether to update the QoS association with the AF. If the ICE candidate type is "relay", this indicates that a TURN server 308 is deployed. In such a case, the 5GMS AF 306 will identify the corresponding QoS flows to the remote port / IP address pair and also request the QoS to be applied to it.

[0064]

[0071] This is applicable to TURN servers hosted within a trusted domain, e.g., TURN server 308. TURN servers outside a Mobile Network Operator (MNO) network do not receive QoS allocations. TURN servers within a trusted domain, e.g., TURN server 308, may be empowered to send QoS flow description updates directly to the 5GMS AF 306. Alternatively, this can be done by a signaling server hosted by the MNO.

[0065]

[0072] Since the TURN server 308 does not contain information indicating the location of the 5GMS AF 306, the 5GMS AF 306 probes the TURN server 308 to detect support for the 5G extension. If the TURN server 308 supports this extension, the TURN server 308 will respond with the actual mapping between the QoS flows and the UE 302A and between the QoS flows and the UE 302B. The 5GMS AF 306 can then apply the QoS specifications to the second segment of the connection. The association can be established by providing a description of the QoS flows to the UE 302A.

[0066]

[0073] FIG. 8 is a block diagram illustrating an example cooperative scenario in which techniques of the present disclosure may be used. The example of FIG. 8 includes a network 320 and mobile network operators (MNOs) 330A, 330B (MNOs 330). The network 320 includes a STUN server 322, a TURN / MCU server 324, and a WebRTC signaling server 326. The MNOs 330 include respective 5 GMS AFs 332A, 332B (5 GMS AFs 332), PCFs / session management functions (SMFs) / network exposure functions (NEFs) 334A, 334B (PCF / SMF / NEFs 334), and user equipments (UEs) 336A, 336B (UEs 336).

[0067]

[0074] The UE 336 may include components similar to those of the client device 120 of FIG. 2. The UE 336 may implement the techniques of this disclosure to initiate a media communication session 338. In this example, the UE 336 is coupled to different respective MNOs 330. That is, the UE 336A is coupled to the MNO 330A, and the UE 336B is coupled to the MNO 330B. The UE 336A may initiate a media communication session 338 with the UE 336B. First, the UE 336A may send a STUN request to the STUN server 322 to determine its own public IP address and port value. The UE 336A may then build a list of ICE candidates that represent the pairs of IP address and port values ​​received from the STUN server 322. The UE 336A may then send the list of ICE candidates to the UE 336B.

[0068]

[0075] In response, the UE 336B may request its public IP address and port value from the STUN server 322. The UE 336B may then generate a list of ICE candidates that includes its own IP address and port value pairs and send this list of ICE candidates back to the UE 336A.

[0069]

[0076] The UE 336A may receive the list of ICE candidates from the UE 336B and then validate the ICE candidates in the list. For example, the UE 336A may send a STUN request to each IP address and port of the ICE candidates and determine which STUN requests result in a response. For each IP address and port pair for which a response to the STUN request is received, the UE 336A may determine that the corresponding ICE candidate is valid. The UE 336B may similarly determine which of the ICE candidates received from the UE 336A are valid.

[0070]

[0077] After determining the valid ICE candidates, the UE 336A may send data representing the valid ICE candidates and quality of service (QoS) flows to the 5GMS AF 332A. The 5GMS AF 332A may provide media control for the media communication session 338. Similarly, the UE 336B may send data representing the valid ICE candidates and QoS flows to the 5GMS AF 332B, which may additionally or alternatively provide media control for the media communication session 338. The UE 336 may negotiate a pair of valid IP ICE candidates for each of the UE 336A and the UE 336B to establish the media communication session 338. Furthermore, the UE 336 may determine an association between a QoS specification and one of the QoS flows for the media communication session and apply the QoS to the media communication session 338 according to the QoS specification.

[0071]

[0078] The example of FIG. 8 provides over-the-top (OTT) WebRTC with 5G support. The WebRTC functionality may be hosted by a WebRTC signaling server 326, which may be an application service provider. The MNO 330 may provide network assistance and QoS to the UE 336. Specifically, the UE 336 may run a corresponding WebRTC application that may pass information to a corresponding MSH of the UE 336. The MSH may invoke the network assistance and QoS using a service-based architecture (SBA) procedure. In one alternative example, the WebRTC signaling server 326 may communicate with the PCF / SMF / NEF 334.

[0072]

[0079] 9 is a block diagram illustrating another example collaborative scenario in which the techniques of the present disclosure may be used. The example of FIG. 9 illustrates a network 340 including a WebRTC signaling server 342 and MNOs 350A, 350B (MNOs 350). MNOs 350 include respective 5GMS AFs 352A, 352B (5GMS AFs 352), PCF / SMF / NEFs 354A, 354B (PCF / SMF / NEFs 354), STUN servers 358A, 358B (STUN servers 358), TURN / MCU servers 360A, 360B (TURN / MCU servers 360), and UEs 356A, 356B (UEs 356).

[0073]

[0080] In general, the process performed by the UE 356 of FIG. 9 may be substantially similar to the process performed by the UE 336 of FIG. 8 to establish and participate in a media communication session 362. However, in this example, instead of separately providing a STUN server and a TURN / MCU server, the MNO 350 provides the respective STUN server 358 and TURN / MCU server 360. Thus, in this example, the WebRTC functionality is provided by a trusted MNO, namely, the MNO 350. The MNO 350 may provide the WebRTC functionality to a customer, such as a user of the UE 356. A WebRTC application executed by the UE 356 may discover the STUN server 358 and the TURN / MCU server 360 via the respective MNO 350 and include them in an ICE negotiation. The STUN server 358 and the TURN / MCU server 360 can extract information such as the network 5-tuple (source IP address, destination IP address, source port, destination port, and protocol) and pass this information to the 5G MS AF 352 and / or the PCF / SMF / NEF 354. The STUN server 358 and the TURN / MCU server 360 may be implemented as a 5G application function or a 5G application server, in various examples.

[0074]

[0081] 10 is a block diagram illustrating another example cooperative scenario in which the techniques of this disclosure may be used. The example of FIG. 10 shows an MNO 370 including a 5GMS AF 372, a PCF / SMF / NEF 374, UEs 376A, 376B (UEs 376), a STUN server 378, a TURN / MCU server 380, and a WebRTC signaling server 382.

[0075]

[0082] In general, the process performed by the UE 376 of FIG. 10 may be substantially similar to the process performed by the UE 336 of FIG. 8 to establish and participate in a media communication session 384. However, in this example, the UEs 376 are each coupled to the same MNO, namely, MNO 370. Similarly, the MNO 370 provides each of the various network components and services used for WebRTC in this example. That is, in this example, there is a WebRTC service facilitated by the MNO. The MNO 370 may own or provide the WebRTC service on behalf of an application provider. This example may be used for split rendering, where the UE 376 performs different parts of the rendering process, for example, for XR, MR, AR, VR, etc. This example may implement a standardized WebRTC signaling protocol.

[0076]

[0083] In this example, the WebRTC signaling server 382 can receive the SDP offer and provide an SDP answer. The WebRTC signaling server 382 can extract the media and 5-tuple information and pass this information to the 5G MS AF 372 and / or the PCF / SMF / NEF 374. The WebRTC signaling server 382 may be implemented as a 5G application function or a 5G application server in some examples.

[0077]

[0084] 11 is a block diagram illustrating another example collaborative scenario in which the techniques of the present disclosure may be used. The example of FIG. 11 shows MNOs 390A, 390B (MNOs 390). Each of the MNOs 390 includes a respective WebRTC signaling server 402A, 402B (WebRTC signaling server 402), a 5GMS AF 392A, 392B (5GMS AF 392), a PCF / SMF / NEF 394A, 394B (PCF / SMF / NEFs 394), a UE 396A, 396B (UE 396), a STUN server 398A, 398B (STUN server 398), and a TURN / MCU server 400A, 400B (TURN / MCU server 400). In this example, UEs 396A and 396B implement the techniques of this disclosure to establish a media communication session 404.

[0078]

[0085] In general, the process performed by the UE 396 of FIG. 11 may be substantially similar to the process performed by the UE 336 of FIG. 8 to establish and participate in a media communication session 404. However, in this example, the MNO 390 includes a respective WebRTC signaling server 402. In this manner, the example of FIG. 11 provides an interoperable WebRTC service; that is, the WebRTC service is facilitated by the MNO and operates across the MNO 390. The WebRTC signaling server 402 can establish a distributed session control protocol using standardized WebRTC signaling for IOP. In this example, the WebRTC signaling server 402, the STUN server 398, and the TURN / MCU server 400 can exchange session parameters across the MNO 390.

[0079]

[0086] The techniques of the present disclosure can achieve certain advantages. For example, they can separate the QoS specification from the QoS flow definition, which can enable separate ICE negotiation. Their capabilities also allow the QoS specification to be extended to cover all segments of a connection. In particular, they support requesting QoS when the TURN server is hosted by the MNO. They also enable a linkage between the QoS specification and the QoS flow description.

[0080]

[0087] Fig. 12 is a flow chart illustrating an example method for implementing the techniques of this disclosure. Although the method of Fig. 11 is described with respect to the client device 120 of Fig. 2, it should be understood that other devices, such as the client device 110 of Fig. 1, the UE 302 of Fig. 7, the UE 336 of Fig. 8, the UE 356 of Fig. 9, the UE 376 of Fig. 10, or the UE 396 of Fig. 11, may also be configured to implement this method or a similar method.

[0081]

[0088] Initially, client device 120 may determine (420) a list of ICE candidates for peer client devices with which to initiate a media communication session. For example, client device 120 may send a request to the peer client device and receive a list of ICE candidates from the peer client device in response to the request. The list of ICE candidates may include a list of IP address and port pairs at which the peer client device can be reached. Each of client device 120 and the peer client devices may be connected to a network device that performs network address translation (NAT) to translate between a 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).

[0082]

[0089] Client device 120 may then validate the ICE candidates in the list of ICE candidates (422). For example, client device 120 may send a STUN request to each IP address and port in the list received from the peer client device and determine that the ICE candidates for which a response to the STUN request was received are valid. Client device 120 may send data representing the QoS flows for the valid ICE candidates to a 5GMS Application Function (AF), which may be performed by a server device forming part of the MNO or other private network to which client device 120 is connected (424).

[0083]

[0090] The client device 120 may then determine one or more of the valid ICE candidates to use for the media communications session (426). For example, the client device 120 may negotiate with the peer network device to determine respective pairs of IP addresses and ports for the client device 120 and each of the peer client devices for the particular media communications session. The client device 120 may then establish the media communications session (428). For example, the client device 120 may implement the techniques discussed with respect to FIG. 5 to establish the particular media communications session, for example, 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.

[0084]

[0091] Additionally, client device 120 may determine QoS specifications and QoS flows for the media communication session (430). Client device 120 may use the QoS specifications and QoS flows associated with the determined ICE candidates for the media communication session to provide data to an application function (e.g., application function 104 of FIG. 1) that causes the application function to apply QoS to the media communication session (432). For example, client device 102 may invoke QoS provided by a mobile network operator (MNO) that operates server device 102 and application 104 of FIG. 1.

[0085]

[0092] Thus, the method of FIG. 11 illustrates an example of a method that includes determining, by a first client device, a list of bidirectional 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 a Quality of Service (QoS) flow associated with one or more of the valid ICE candidates to a server device that executes an Application Function (AF) that provides media control for the media communications session; determining, by the first client device, one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates; establishing, by the first client device, a media communications 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 one of the QoS flows for the media communications session; and providing, by the first client device, data to the AF for applying QoS to the media communications session in accordance with the QoS specification.

[0086]

[0093] Some example techniques of the present disclosure are summarized in the following paragraphs.

[0087]

[0094] Clause 1: A method for applying quality of service to a media communication session, the method comprising: determining, by a first client device, a list of bidirectional 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 one or more lists of ICE candidates; and, for one or more of the valid ICE candidates, sending, by the first client device, data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device that executes an application function (AF) that provides 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 one of the valid ICE candidates; determining, by the first client device, an association between a QoS specification and one of the QoS flows; and applying, by the first client device, QoS to the communication session in accordance with the QoS specification.

[0088]

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

[0089]

[0096] Clause 3: The method of any of clauses 1 and 2, wherein the data representing QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0090]

[0097] Clause 4: The method of any of clauses 1 to 3, wherein the data representative of QoS flows associated with one or more of the valid ICE candidates includes data describing service data flows for which QoS is to be provided.

[0091]

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

[0092]

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

[0093]

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

[0094]

[0101] Clause 13: A device as described in clause 12, wherein the one or more means comprise one or more processors implemented in circuitry.

[0095]

[0102] Clause 14. A device according to any of clauses 12 and 13, further comprising a display.

[0096]

[0103] Clause 15: A device according to any of clauses 12 to 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.

[0097]

[0104] Clause 16: A device according to any one of clauses 12 to 15, further comprising a memory.

[0098]

[0105] Clause 17: A computer-readable storage medium storing instructions that, when executed, cause a processor to perform a method according to any one of clauses 1 to 6.

[0099]

[0106] 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 bidirectional connectivity establishment (ICE) candidates; means for sending a media communication session request to a second client device 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device executing an application function (AF) that provides media control for the communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates; means for determining an association between a QoS specification and one of the QoS flows; and means for applying QoS to the communication session in accordance with the QoS specification.

[0100]

[0107] 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 bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device that executes an application function (AF) that provides 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 one of the valid ICE candidates; establishing, by the first client device, a 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 one of the QoS flows for the media communication session; and providing, by the first client device, data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0101]

[0108] Clause 20: The method of clause 19, wherein determining the list of ICE candidates includes 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.

[0102]

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

[0103]

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

[0104]

[0111] 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.

[0105]

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

[0106]

[0113] Clause 25: The method of clause 19, wherein the data representing QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0107]

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

[0108]

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

[0109]

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

[0110]

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

[0111]

[0118] 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, the one or more processors configured to: determine a list of bidirectional connectivity establishment (ICE) candidates for a second client device, determine valid ICE candidates in the list of ICE candidates, and for one or more of the valid ICE candidates, send data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides media control for the media communication session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a 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 one of the QoS flows for the media communication session, and provide data to the AF to apply QoS to the media communication session in accordance with the QoS specification.

[0112]

[0119] Clause 31: 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, in the first client device described in Clause 30.

[0113]

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

[0114]

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

[0115]

[0122] 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.

[0116]

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

[0117]

[0124] Clause 36: The first client device of clause 30, wherein the data representing QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0118]

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

[0119]

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

[0120]

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

[0121]

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

[0122]

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

[0123]

[0130] 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.

[0124]

[0131] Clause 43: A computer-readable storage medium having instructions stored thereon that, when executed, cause a processor of a first client device to determine a list of bidirectional 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 a Quality of Service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an Application Function (AF) that provides media control for the media communications session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a media communications session with the second client device using the determined one of the valid ICE candidates, determine an association between a QoS specification and one of the QoS flows for the media communications session, and provide data to the AF for applying QoS to the media communications session in accordance with the QoS specification.

[0125]

[0132] Clause 44: A computer-readable storage medium as described in Clause 43, wherein the instructions for causing the processor to determine the list of ICE candidates include instructions for causing 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.

[0126]

[0133] Clause 45: A computer-readable storage medium as described in Clause 43, wherein the first client device is communicatively coupled to a first mobile network operator (MNO) and the second client device is communicatively coupled to a second MNO, and the instructions for causing the processor to provide data to an application function to apply QoS to the media communication session include instructions for causing the processor to invoke QoS provided by the first MNO using a service based architecture (SBA) procedure provided by the first MNO.

[0127]

[0134] Clause 46: A computer-readable storage medium as described in Clause 43, wherein a first client device is communicatively coupled to a first mobile network operator (MNO) and a second client device is communicatively coupled to a second MNO, and the instructions for causing the processor to determine a list of ICE candidates comprise instructions for causing the processor to receive data representing one or more of the ICE candidates from the first MNO.

[0128]

[0135] 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.

[0129]

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

[0130]

[0137] Clause 49: The computer-readable storage medium of clause 43, wherein the data representing the QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0131]

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

[0132]

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

[0133]

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

[0134]

[0141] Clause 53: The computer-readable storage medium of clause 43, wherein the media communication session includes a Web Real-Time Communications (WebRTC) communication session.

[0135]

[0142] 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 bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides media control for the media communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates; means for establishing a 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 one of the QoS flows for the media communication session; and means for providing data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0136]

[0143] 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 bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides 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 one of the valid ICE candidates; establishing, by the first client device, a 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 one of the QoS flows for the media communication session; and providing, by the first client device, data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0137]

[0144] Clause 56: The method of clause 55, wherein determining the list of ICE candidates includes 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.

[0138]

[0145] Clause 57: A method as described in any of clauses 55 and 56, wherein the first client device is communicatively coupled to a first mobile network operator (MNO) and the second client device is communicatively coupled to a second MNO, and providing data to an application function to apply QoS to the media communication session includes invoking QoS provided by the first MNO using a service based architecture (SBA) procedure provided by the first MNO.

[0139]

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

[0140]

[0147] 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.

[0141]

[0148] Clause 60: A method according to any of clauses 55 to 59, further comprising receiving data from a server device running the AF, representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server.

[0142]

[0149] Clause 61: The method of any of clauses 55 to 60, wherein the data representing QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0143]

[0150] Clause 62: The method of any of clauses 55 to 61, wherein the data representative of QoS flows associated with one or more of the valid ICE candidates comprises data describing service data flows for which QoS is to be provided.

[0144]

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

[0145]

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

[0146]

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

[0147]

[0154] 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, the one or more processors configured to: determine a list of bidirectional connectivity establishment (ICE) candidates for a second client device, determine valid ICE candidates in the list of ICE candidates, and for one or more of the valid ICE candidates, send data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides media control for the media communication session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a 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 one of the QoS flows for the media communication session, and provide data to the AF to apply QoS to the media communication session in accordance with the QoS specification.

[0148]

[0155] Clause 67: The first client device described in 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.

[0149]

[0156] Clause 68: A first client device as described in any of clauses 66 and 67, wherein the first client device is communicatively coupled to a first mobile network operator (MNO) and the second client device is communicatively coupled to a second MNO, and in order to provide data to an 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 provided by the first MNO.

[0150]

[0157] Clause 69: A first client device as described in any of Clauses 66 and 67, wherein the first client device is communicatively coupled to a first mobile network operator (MNO) and the second client device is communicatively coupled to a second MNO, and to determine a 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.

[0151]

[0158] Clause 70: A first client device described in 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.

[0152]

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

[0153]

[0160] Clause 72: A first client device described in any of clauses 66 to 71, wherein the data representing a QoS flow associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0154]

[0161] Clause 73: A first client device as described in any of clauses 66 to 72, wherein the data representing a QoS flow associated with one or more of the valid ICE candidates includes data describing a service data flow for which QoS is to be provided.

[0155]

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

[0156]

[0163] Clause 75: A first client device described in any of clauses 66 to 74, wherein the one or more processors are further configured to send an update message to a server device performing AF, the update message including data associating one of the valid ICE candidates with one of the QoS flows.

[0157]

[0164] Clause 76. A first client device according to any of clauses 66 to 75, wherein the media communication session comprises a Web Real-Time Communications (WebRTC) communication session.

[0158]

[0165] Clause 77: The first client device described in any of clauses 66 to 76, further comprising a display.

[0159]

[0166] Clause 78: The first client device of any of Clauses 66 to 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.

[0160]

[0167] Clause 79: A computer-readable storage medium having instructions stored thereon that, when executed, cause a processor of a first client device to determine a list of bidirectional 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 a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides media control for the media communications session, determine one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates, establish a media communications session with the second client device using the determined one of the valid ICE candidates, determine an association between a QoS specification and one of the QoS flows for the media communications session, and provide the data to the AF to apply QoS to the media communications session in accordance with the QoS specification.

[0161]

[0168] Clause 80: A computer-readable storage medium as described in clause 79, wherein the instructions for causing the processor to determine a list of ICE candidates include instructions for causing 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.

[0162]

[0169] Clause 81: A computer-readable storage medium as described in any of clauses 79 and 80, wherein a first client device is communicatively coupled to a first mobile network operator (MNO) and a second client device is communicatively coupled to a second MNO, and the instructions for causing the processor to provide data to an application function to apply QoS to the media communication session include instructions for causing the processor to invoke QoS provided by the first MNO using a service-based architecture (SBA) procedure provided by the first MNO.

[0163]

[0170] Clause 82: A computer-readable storage medium as described in any of clauses 79 and 80, wherein a first client device is communicatively coupled to a first mobile network operator (MNO) and a second client device is communicatively coupled to a second MNO, and the instructions for causing the processor to determine a list of ICE candidates comprise instructions for causing the processor to receive data representing one or more of the ICE candidates from the first MNO.

[0164]

[0171] Clause 83: A computer-readable storage medium according to 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.

[0165]

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

[0166]

[0173] Clause 85: A computer-readable storage medium according to any of clauses 79 to 84, wherein the data representing the QoS flows associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0167]

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

[0168]

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

[0169]

[0176] Clause 88: A computer-readable storage medium as described in any of clauses 79 to 87, further comprising instructions that cause the processor to send an update message to a server device running AF, the update message including data associating one of the valid ICE candidates with one of the QoS flows.

[0170]

[0177] Clause 89: A computer-readable storage medium according to any of clauses 79 to 88, wherein the media communication session comprises a Web Real-Time Communications (WebRTC) communication session.

[0171]

[0178] 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 bidirectional connectivity establishment (ICE) candidates for a second client device; means for determining valid ICE candidates in the list of ICE candidates; means for transmitting, for one or more of the valid ICE candidates, data representing a quality of service (QoS) flow associated with one or more of the valid ICE candidates to a server device running an application function (AF) that provides media control for the media communication session; means for determining one of the valid ICE candidates and one of the QoS flows associated with one of the valid ICE candidates; means for establishing a 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 one of the QoS flows for the media communication session; and means for providing data to the AF for applying QoS to the media communication session in accordance with the QoS specification.

[0172]

[0179] Item 91: The first client device described in 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.

[0173]

[0180] Clause 92: A first client device as described in any of clauses 90 and 91, wherein the first client device is communicatively coupled to a first mobile network operator (MNO) and the second client device is communicatively coupled to a second MNO, and the means for providing data to an 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 provided by the first MNO.

[0174]

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

[0175]

[0182] Clause 94: A first client device described in 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.

[0176]

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

[0177]

[0184] Clause 96: A first client device as described in any of clauses 90 to 95, wherein the data representing a QoS flow associated with one or more of the valid ICE candidates includes data representing an association between a QoS flow description and a QoS specification.

[0178]

[0185] Clause 97: A first client device as described in any of clauses 90 to 96, wherein the data representing a QoS flow associated with one or more of the valid ICE candidates includes data describing a service data flow for which QoS is to be provided.

[0179]

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

[0180]

[0187] Clause 99: A first client device as described in any of clauses 90 to 98, further comprising means for sending an update message to a server device performing AF, the update message including data associating one of the valid ICE candidates with one of the QoS flows.

[0181]

[0188] Clause 100. The first client device of any of clauses 90-99, wherein the media communication session includes a Web Real-Time Communications (WebRTC) communication session.

[0182]

[0189] Clause 101: A method for applying quality of service to a media communication session, the method comprising: receiving, by a server device executing an application function (AF) providing media control for a media communication session between a first client device and a second client device, data from the first client device representing quality of service (QoS) flows associated with one or more valid bidirectional connectivity establishment (ICE) candidates for the first client device; receiving, by the server device, data from the first client device 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0183]

[0190] Clause 102: A server device for applying quality of service to a media communication session, the device comprising: a memory configured to store an association between a quality of service (QoS) flow and one or more valid bidirectional connectivity establishment (ICE) candidates for a first client device; and one or more processors implemented in circuitry configured to execute an application function (AF) that provides 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 an association between the QoS flow and 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0184]

[0191] Clause 103: A computer-readable storage medium having instructions stored thereon, the instructions causing a processor of a server device to execute an application function (AF) that provides media control for a media communication session between a first client device and a second client device, to receive from the first client device data representing Quality of Service (QoS) flows associated with one or more valid bidirectional connectivity establishment (ICE) candidates for the first client device, to receive from the first client device data representing an association between one of the QoS flows and an associated QoS specification, and to apply QoS to the media communication session in accordance with the QoS specification corresponding to one of the QoS flows.

[0185]

[0192] 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) that provides 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 bidirectional 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 in accordance with the QoS specification corresponding to one of the QoS flows.

[0186]

[0193] It should be appreciated that, depending on the example, some acts or events of any of the techniques described herein can be performed in a different order, or may be added, combined, or omitted entirely (e.g., not all acts or events described are necessary to the practice of the techniques). Moreover, in some examples, acts or events may be performed in parallel rather than sequentially, for example, through multi-threaded processing, interrupt processing, or multiple processors.

[0187]

[0194] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted via a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium, such as a data storage medium, or a communication medium, which includes any medium that facilitates transfer of a computer program from one place to another, for example, according to a communication protocol. As such, a computer-readable medium may generally correspond to (1) a tangible computer-readable storage medium that is non-transitory, or (2) a communication medium, such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0188]

[0195] By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer readable media.

[0189]

[0196] The 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. Thus, the terms "processor" and "processing circuitry" as used herein may refer to any of the above structures, or any other structure suitable for implementing the techniques described herein. The techniques may also be implemented entirely in one or more circuits or logic elements.

[0190]

[0197] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units have been described in this disclosure to highlight functional aspects of devices configured to implement the disclosed techniques, but they do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit or may be provided by a collection of interoperable hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0191]

[0198] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for applying quality of service to a media communication session, comprising: determining, by a first client device, a list of bidirectional 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, transmitting, by the first client device, data representing a quality of service (QoS) flow associated with the one or more of the valid ICE candidates to a server device executing an application function (AF) that provides 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; providing, by the first client device, data to the AF to apply QoS to the media communication session according to the QoS specification; A method comprising the above steps.

2. The first client device is communicatively coupled to a first mobile network operator (MNO), and the second client device is communicatively coupled to a second MNO, The method according to claim 1, wherein providing the data to the AF to apply QoS to the media communication session comprises invoking QoS provided by the first MNO using service-based architecture (SBA) procedures provided by the first MNO.

3. The first client device is communicatively coupled to a first mobile network operator (MNO), and the second client device is communicatively coupled to a second MNO, The method according to claim 1, wherein determining the list of ICE candidates comprises receiving data representing one or more of the ICE candidates from the first MNO.

4. The method according to claim 1, 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.

5. The method according to claim 1, further comprising receiving data representing at least one of a Traversal Using Relay Network Address Translation (TURN) server or a Session Traversal of UDP (STUN) server from the server device that executes the AF.

6. A first client device for applying quality of service to a media communication session, a memory configured to store media data, one or more processors implemented in a circuit mechanism, wherein the one or more processors determine a list of candidates for bidirectional connectivity establishment (ICE) for a second client device, determine valid ICE candidates in the list of ICE candidates, for one or more of the valid ICE candidates, transmit data representing a quality of service (QoS) flow associated with the one or more of the valid ICE candidates to a server device that executes an application function (AF) that provides 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, A first client device configured to provide data to the AF to apply QoS to the media communication session according to the QoS specification.

7. The first client device is communicatively coupled to a first mobile network operator (MNO), and the second client device is communicatively coupled to a second MNO. To provide data to the AF for applying QoS to the media communication session, the one or more processors are configured to invoke the QoS provided by the first MNO using service-based architecture (SBA) procedures provided by the first MNO. The first client device according to claim 6.

8. The first client device is communicatively coupled to a first mobile network operator (MNO), and the second client device is communicatively coupled to a second MNO. 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. The first client device according to claim 6.

9. The first client device according to claim 6, 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.

10. The first client device according to claim 6, wherein the one or more processors are further configured to receive data representing at least one of a Traversal Using Relay NAT (TURN) server or a Session Traversal of UDP (STUN) server from the server device executing the AF.

11. A computer-readable storage medium storing instructions that, when executed, cause a processor of a first client device to determine a list of bidirectional 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, cause data representing a quality of service (QoS) flow associated with the one or more of the valid ICE candidates to be transmitted to a server device executing an application function (AF) that provides media control for the media communication session. Cause one of the valid ICE candidates and one of the QoS flows associated with said one of the valid ICE candidates to be determined; Use the determined one of the valid ICE candidates to establish the media communication session with the second client device; Cause an association to be determined between the QoS specification and one of the QoS flows for the media communication session; A computer-readable storage medium for causing data to be provided to the AF to apply QoS to the media communication session according to the QoS specification. A method for applying quality of service to a media communication session, Receiving, by a server device executing an Application Function (AF) that provides media control for a media communication session between a first client device and a second client device, from the first client device, data representing a Quality of Service (QoS) flow associated with one or more valid Bidirectional Connectivity Establishment (ICE) candidates for the first client device; Receiving, by the server device, from the first client device, data representing an association between one of the QoS flows and an associated QoS specification; Applying QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows; A method comprising: A server device for applying quality of service to a media communication session, A memory configured to store an association between a Quality of Service (QoS) flow and one or more valid Bidirectional Connectivity Establishment (ICE) candidates related to a first client device; One or more processors implemented in circuitry, the one or more processors Execute an Application Function (AF) that provides media control for a media communication session between the first client device and the second client device; Receiving, from the first client device, data representing the association between a QoS flow and the one or more valid ICE candidates for the first client device; ​ ​ Receive data representing an association between one of the QoS flows and an associated QoS specification from the first client device. Configured to apply QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows by the server device. Server device. **Claim 14** A computer-readable storage medium storing instructions, the instructions causing a processor of a server device to Execute an application function (AF) that provides media control for a media communication session between a first client device and a second client device. Receive data representing a quality of service (QoS) flow associated with one or more valid bidirectional connectivity establishment (ICE) candidates for the first client device from the first client device. Receive data representing an association between one of the QoS flows and an associated QoS specification from the first client device. Apply QoS to the media communication session according to the QoS specification corresponding to the one of the QoS flows. Computer-readable storage medium.

Images