5G support for WEBRTC

By implementing media session handler and ICE negotiation in user equipment, the quality problem of media data transmission in WebRTC sessions is solved, and the audio and video data transmission efficiency in 5G networks is improved, and it is suitable for XR applications.

CN119096529APending Publication Date: 2024-12-06QUALCOMM INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380036769.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-05-01
Filing Date
2023-05-02
Publication Date
2024-12-06

AI Technical Summary

Technical Problem

The prior art has difficulty in efficiently supporting the media data transmission of network real-time communication (WebRTC) sessions in 5G networks, especially in audio and video data transmission involving extended reality (XR) applications, with packet loss and latency issues.

Method used

By implementing media session handler (MSH) in user equipment (UE), interacting with application provider devices, using ICE negotiation and STUN/TURN server to make binding requests, ensuring the quality of WebRTC sessions and codec configuration, optimizing media Transmission of data.

Benefits of technology

It improves the quality and stability of media data transmission in WebRTC sessions, reduces packet loss and delay, supports efficient audio and video data transmission, and is suitable for XR application scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119096529A_ABST
    Figure CN119096529A_ABST
Patent Text Reader

Abstract

An example apparatus for exchanging media data includes a memory configured to store media data; and one or more processors implemented in circuitry and configured to execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a session traversal utility (STUN) application function for network address translation, or a traversal (TURN) application function using relays around the NAT; receiving a web application from the application provider device; and exchanging media data between the one or more application functions provided by the application provider device, the MSH, and the web application.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application claims priority to U.S. Patent Application No. 18 / 310,128, filed May 1, 2023, U.S. Provisional Application No. 63 / 484,568, filed February 13, 2023, and U.S. Provisional Patent Application No. 63 / 364,184, filed May 4, 2022, each of which is hereby incorporated by reference in its entirety. U.S. Patent Application No. 18 / 310,128, filed May 1, 2023, claims the benefit of U.S. Provisional Application No. 63 / 484,568, filed February 13, 2023, and U.S. Provisional Patent Application No. 63 / 364,184, filed May 4, 2022. Technical Field

[0002] The present disclosure relates to the storage and transmission of encoded video data. Background Art

[0003] Digital video capabilities may be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radiotelephones, video teleconferencing equipment, etc. Digital video devices implement video compression techniques, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263 or ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), ITU-T H.265 (also known as High Efficiency Video Coding (HEVC)), and extensions of these standards, to more efficiently send and receive digital video information.

[0004] Video compression techniques perform spatial prediction and / or temporal prediction to reduce or remove redundancy inherent in video sequences. For block-based video coding, a video frame or slice can be divided into macroblocks. Each macroblock can be further divided. Macroblocks in an intra-coded (I) frame or slice can be encoded using spatial predictions for adjacent macroblocks. Macroblocks in an inter-coded (P or B) frame or slice can use spatial predictions for adjacent macroblocks in the same frame or slice or temporal predictions for other reference frames.

[0005] After encoding the video data, the video data may be packaged for transmission or storage. The video data may be assembled into a video file that conforms to any of a variety of standards, such as the International Organization for Standardization (ISO) base media file format and its extensions, such as AVC. Summary of the invention

[0006] In general, the present disclosure describes techniques for initiating a web real-time communication (WebRTC) session (e.g., for exchanging media data including audio, image, and / or video data). A WebRTC session may be initiated in a 5G communication system. WebRTC may be used to exchange media data, such as media data for an extended reality (XR) session, which may include an augmented reality (AR), mixed reality (MR), or virtual reality (VR) communication session, including audio and video data and XR data. A user equipment (UE) involved in a WebRTC session may include a media session handler (MSH) that negotiates with one or more application functions (AFs) of an application server. In addition, the UE may retrieve a network application from an application provider (AP) using the MSH. The network application may be configured to participate in an XR session, and the local WebRTC application may be configured to transmit and receive data via the MSH according to WebRTC.

[0007] In one example, a device for exchanging media data includes: a memory configured to store media data; and one or more processors implemented in a circuit and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device; and execute the application to: retrieve configuration information related to Web Real-Time Communication (WebRTC) from the MSH; and use the configuration information to establish a WebRTC session and exchange media data via the WebRTC session.

[0008] In another example, a method for exchanging media data includes: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; executing the application to retrieve configuration information related to Web Real-Time Communication (WebRTC) from the MSH; and executing the application to use the configuration information to establish a WebRTC session and exchange media data via the WebRTC session.

[0009] In another example, a computer-readable storage medium has instructions stored thereon that, when executed, cause a processor to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device; execute an application to retrieve configuration information related to Web Real-Time Communications (WebRTC) from the MSH; and execute the application to use the configuration information to establish a WebRTC session and exchange media data via the WebRTC session.

[0010] In another example, a device for exchanging media data includes: a component for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; a component for executing an application to retrieve configuration information related to web real-time communication (WebRTC) from the MSH; and a component for exchanging data between the one or more application functions provided by the application provider device, the MSH and the network application.

[0011] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram illustrating an example system that implements techniques for streaming media data over a network.

[0013] Figure 2 is a block diagram illustrating an architecture 100 of a system that may be configured to perform immersive real-time communications (iRTCW) for web real-time communications (WebRTC) in accordance with techniques of this disclosure.

[0014] Figure 3 is a call flow diagram illustrating an example method for initiating a WebRTC media session according to techniques of this disclosure.

[0015] Figure 4 is a flow chart illustrating an example method of establishing a WebRTC session in a radio access network according to the techniques of this disclosure. DETAILED DESCRIPTION

[0016] In general, the present disclosure describes technologies for providing support for Web Real-Time Communications (WebRTC) in a radio access network (RAN) such as a 5G network. As part of a WebRTC session, a user equipment (UE) may transmit and receive extended reality (XR) data, such as augmented reality (AR) data, mixed reality (MR) data, and / or virtual reality (VR) data, along with audio and / or video data. For example, the UE may transmit user avatar information representing the user's appearance in a virtual scene, the user's posture and / or movement information, actions performed by the user, and the like. The UE may receive audio, video, and / or XR data, for example, based on the user's posture, movement, and interaction with the virtual scene, as well as based on other participants in the WebRTC session. Therefore, multiple UEs may be involved in a WebRTC session, for example, for a virtual conference call, video game, or other such scenario in a virtual scene.

[0017] According to the technology of the present disclosure, the UE may include a media session handler (MSH) and a local WebRTC application. The WebRTC application may be configured to transmit and receive WebRTC session data via the MSH, and the MSH may use one or more application functions (AFs) of a trusted RTCAF server to transmit and receive data. In order to determine the RTC AF server, the MSH may initially perform an interactive connection establishment (ICE) negotiation. The ICE negotiation may generally involve retrieving a list of ICE candidates and selecting one of the ICE candidates to be used for the WebRTC session. The ICE candidate may be, for example, a Session Traversal Utility (STUN) for Network Address Translation and / or a Traversal (TURN) server candidate using NAT Relays Around that provides 5G RTC functionality. The MSH may also retrieve media configuration recommendations. The MSH may provide data representing ICE candidates and media configuration recommendations to the network application.

[0018] The network application may then construct a request for a WebRTC session (or a response to a request) and transmit the request to one of the ICE candidates. After one of the ICE candidates validates the request, the UE may receive a binding information and quality of service (QoS) and codec recommendation from one of the ICE candidates. The UE's application may then update a Session Description Protocol (SDP) offer or answer based on the information received from the ICE candidate, and use the updated SDP offer / answer to establish a WebRTC media session, for example, with one or more other UEs and / or a media server.

[0019] Figure 1 is a block diagram illustrating an example system 10 implementing techniques for streaming media data over a network. In this example, system 10 includes content preparation device 20, server device 60, and client device 40. Client device 40 and server device 60 are communicatively coupled via network 74, which may include the Internet. In some examples, content preparation device 20 and server device 60 may also be coupled via network 74 or another network, or may be directly communicatively coupled. In some examples, content preparation device 20 and server device 60 may include the same device.

[0020] exist Figure 1In the example of , content preparation device 20 includes an audio source 22 and a video source 24. Audio source 22 may include, for example, a microphone that generates an electrical signal representing captured audio data to be encoded by audio encoder 26. Alternatively, audio source 22 may include: a storage medium that stores previously recorded audio data; an audio data generator, such as a computerized synthesizer; or any other source of audio data. Video source 24 may include: a video camera that generates video data to be encoded by video encoder 28; a storage medium encoded with previously recorded video data; a video data generation unit, such as a computer graphics source; or any other source of video data. Content preparation device 20 is not necessarily communicatively coupled to server device 60 in all examples, but the multimedia content may be stored to a separate medium that is read by server device 60.

[0021] The raw audio and video data may include analog or digital data. The analog data may be digitized before being encoded by the audio encoder 26 and / or the video encoder 28. As the speaking participant is speaking, the audio source 22 may obtain audio data from the speaking participant, and the video source 24 may simultaneously obtain video data of the speaking participant. In other examples, the audio source 22 may include a computer-readable storage medium containing stored audio data, and the video source 24 may include a computer-readable storage medium containing stored video data. In this way, the techniques described in the present disclosure may be applied to live, streaming, real-time audio and video data, or to archived, pre-recorded audio and video data.

[0022] An audio frame corresponding to a video frame is typically an audio frame containing audio data that is captured (or generated) by audio source 22 simultaneously with video data captured (or generated) by video source 24 and contained within the video frame. For example, when a speaking participant typically generates audio data by speaking, audio source 22 captures audio data, and video source 24 simultaneously (i.e., while audio source 22 is capturing audio data) captures video data of the speaking participant. Thus, an audio frame may correspond in time to one or more specific video frames. Thus, an audio frame corresponding to a video frame typically corresponds to a situation in which audio data and video data are captured simultaneously, and for which the audio frame and video frame include the audio data and video data captured simultaneously, respectively.

[0023] In some examples, audio encoder 26 may encode a timestamp into each encoded audio frame, wherein the timestamp indicates the time at which audio data for the encoded audio frame was recorded, and similarly, video encoder 28 may encode a timestamp into each encoded video frame, wherein the timestamp indicates the time at which video data for the encoded video frame was recorded. In such examples, an audio frame corresponding to a video frame may include: an audio frame including a timestamp, and a video frame including the same timestamp. Content preparation device 20 may include an internal clock, wherein audio encoder 26 and / or video encoder 28 may generate timestamps based on the internal clock, or audio source 22 and video source 24 may use the internal clock to associate audio and video data with timestamps, respectively.

[0024] In some examples, audio source 22 may transmit data corresponding to the time at which the audio data was recorded to audio encoder 26, and video source 24 may transmit data corresponding to the time at which the video data was recorded to video encoder 28. In some examples, audio encoder 26 may encode a sequence identifier into the encoded audio data to indicate the relative temporal ordering of the encoded audio data without necessarily indicating the absolute time at which the audio data was recorded, and similarly, video encoder 28 may also use the sequence identifier to indicate the relative temporal ordering of the encoded video data. Similarly, in some examples, the sequence identifier may be mapped or otherwise associated with a timestamp.

[0025] The audio encoder 26 usually produces an encoded audio data stream, while the video encoder 28 produces an encoded video data stream. Each individual data stream (whether audio or video) can be referred to as an elementary stream. An elementary stream is a single, digitally decoded (possibly compressed) component of a media presentation. For example, the decoded video or audio portion of a media presentation can be an elementary stream. An elementary stream can be converted into a packaged elementary stream (PES) before being encapsulated into a video file. Within the same media presentation, a stream ID can be used to distinguish the PES packets belonging to an elementary stream from the PES packets belonging to other elementary streams. The basic unit of the data of an elementary stream is a packaged elementary stream (PES) packet. Therefore, the decoded video data usually corresponds to an elementary video stream. Similarly, audio data corresponds to one or more corresponding elementary streams.

[0026] exist Figure 1In the example of , encapsulation unit 30 of content preparation device 20 receives an elementary stream including decoded video data from video encoder 28, and receives an elementary stream including decoded audio data from audio encoder 26. In some examples, video encoder 28 and audio encoder 26 may each include a packetizer for forming PES packets from the encoded data. In other examples, video encoder 28 and audio encoder 26 may each interface with a corresponding packetizer for forming PES packets from the encoded data. In other examples, encapsulation unit 30 may include a packetizer for forming PES packets from the encoded audio and video data.

[0027] The video encoder 28 may encode the video data of the multimedia content in various ways to generate different representations of the multimedia content at various bit rates and with various characteristics, such as pixel resolution, frame rate, compliance with various coding standards, compliance with various profiles and / or profile levels for various coding standards, representations with one or more views (e.g., for two-dimensional or three-dimensional playback), or other such characteristics. As used in the present disclosure, a representation may include one of the following: audio data, video data, text data (e.g., for closed captions), or other such data. A representation may include elementary streams, such as an audio elementary stream or a video elementary stream. Each PES packet may include a stream_id, which identifies the elementary stream to which the PES packet belongs. Encapsulation unit 30 is responsible for assembling elementary streams into streamable media data.

[0028] Encapsulation unit 30 receives PES packets of elementary streams for media presentation from audio encoder 26 and video encoder 28, and forms corresponding network abstraction layer (NAL) units according to the PES packets. The encoded video segments can be organized into NAL units, which provide "network-friendly" video representations for addressing applications such as video telephony, storage, broadcasting, or streaming. NAL units can be classified into video coding layer (VCL) NAL units and non-VCL NAL units. VCL units can contain core compression engines and can include block, macroblock, and / or slice level data. Other NAL units can be non-VCL NAL units. In some examples, a decoded picture in a time instance (usually presented as a primary decoded picture) can be included in an access unit, where an access unit can include one or more NAL units.

[0029] Non-VCL NAL units may include parameter set NAL units and SEI NAL units, among others. Parameter sets may contain sequence level header information (in a sequence parameter set (SPS)) and rarely changing picture level header information (in a picture parameter set (PPS)). With parameter sets (e.g., PPS and SPS), rarely changing information does not need to be repeated for each sequence or picture; therefore, coding efficiency may be improved. In addition, the use of parameter sets may enable out-of-band transmission of important header information, thereby avoiding the need for redundant transmission for error recovery. In an example of out-of-band transmission, parameter set NAL units may be sent on a different channel from other NAL units (such as SEI NAL units).

[0030] Supplemental enhancement information (SEI) may contain information that is not necessary for decoding coded picture samples from VCL NAL units but may assist processes related to decoding, display, error recovery, and other purposes. SEI messages may be included in non-VCL NAL units. SEI messages are a normative part of some standard specifications and are therefore not always mandatory for standard-compliant decoder implementations. SEI messages may be sequence-level SEI messages or picture-level SEI messages. Some sequence-level information may be included in SEI messages, such as scalable information SEI messages in the example of SVC, and view scalable information SEI messages in MVC. These example SEI messages may convey information about, for example, the extraction of operation points and the characteristics of the operation points.

[0031] The server device 60 includes a real-time transport protocol (RTP) sending unit 70 and a network interface 72. In some examples, the server device 60 may include multiple network interfaces. In addition, any or all features of the server device 60 may be implemented on other devices (such as routers, bridges, proxy devices, switches, or other devices) of the content delivery network. In some examples, an intermediate device of the content delivery network may cache data of the multimedia content 64 and include components that substantially conform to the components of the server device 60. Generally speaking, the network interface 72 is configured to transmit and receive data via the network 74.

[0032] The RTP sending unit 70 is configured to deliver media data to the client device 40 via the network 74 according to RTP, which is standardized in the request for comments (RFC) 3550 of the Internet Engineering Task Force (IETF). The RTP sending unit 70 can also implement protocols related to RTP, such as RTP Control Protocol (RTCP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP) and / or Session Description Protocol (SDP). The RTP sending unit 70 can transmit the media data via a network interface 72, which can implement a unified datagram protocol (UDP) and / or an Internet Protocol (IP). Therefore, in some examples, the server device 60 can use the network 74 to transmit media data via RTP and RTSP on UDP.

[0033] The RTP sending unit 70 may receive an RTSP describe request from, for example, the client device 40. The RTSP describe request may include data indicating what types of data are supported by the client device 40. The RTP sending unit 70 may respond to the client device 40 with data indicating a media stream, such as the media content 64, which may be transmitted to the client device 40 along with a corresponding network location identifier, such as a uniform resource locator (URL) or uniform resource name (URN).

[0034] The RTP sending unit 70 may then receive an RTSP setup request from the client device 40. The RTSP setup request may generally indicate how the media stream will be transmitted. The RTSP setup request may contain a network location identifier and a transport specifier for the requested media data (e.g., media content 64), such as a local port for receiving RTP data and control data (e.g., RTCP data) on the client device 40. The RTP sending unit 70 may reply to the RTSP setup request with an acknowledgement and data representing the port of the server device 60 through which the RTP data and control data will be transmitted. The RTP sending unit 70 may then receive an RTSP play request so that the media stream is "played," i.e., transmitted to the client device 40 via the network 74. The RTP sending unit 70 may also receive an RTSP teardown request to end the streaming session, in response to which the RTP sending unit 70 may stop transmitting media data for the corresponding session to the client device 40.

[0035] Likewise, the RTP receiving unit 52 may initiate a media stream by initially transmitting an RTSP describe request to the server device 60. The RTSP describe request may indicate the types of data supported by the client device 40. The RTP receiving unit 52 may then receive a reply from the server device 60 specifying available media streams, such as media content 64, that may be transmitted to the client device 40 along with a corresponding network location identifier, such as a uniform resource locator (URL) or uniform resource name (URN).

[0036] The RTP receiving unit 52 may then generate an RTSP setup request and transmit the RTSP setup request to the server device 60. As described above, the RTSP setup request may include a network location identifier for the requested media data (e.g., media content 64) and a transport specifier, such as a local port for receiving the RTP data and control data (e.g., RTCP data) at the client device 40. In response, the RTP receiving unit 52 may receive an acknowledgement from the server device 60, including the port of the server device 60 that the server device 60 will use to transmit the media data and the control data.

[0037] After the media streaming session is established between the server device 60 and the client device 40, the RTP sending unit 70 of the server device 60 may transmit the media data (e.g., packets of the media data) to the client device 40 according to the media streaming session. The server device 60 and the client device 40 may exchange control data (e.g., RTCP data) indicating, for example, reception statistics of the client device 40, so that the server device 60 may perform congestion control or otherwise diagnose and resolve transmission failures.

[0038] The network interface 54 may receive the media of the selected media presentation and provide the media of the selected media presentation to the RTP receiving unit 52, which in turn may provide the media data to the decapsulation unit 50. The decapsulation unit 50 may decapsulate the elements of the video file into constituent PES streams, depacketize the PES streams to retrieve the encoded data, and transmit the encoded data to the audio decoder 46 or the video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream (e.g., as indicated by the PES packet header of the stream). The audio decoder 46 decodes the encoded audio data and transmits the decoded audio data to the audio output 42, while the video decoder 48 decodes the encoded video data and transmits the decoded video data (which may include multiple views of the stream) to the video output 44.

[0039] The video encoder 28, the video decoder 48, the audio encoder 26, the audio decoder 46, the encapsulation unit 30, the RTP receiving unit 52, and the decapsulation unit 50 can all be implemented as any of a variety of suitable processing circuits, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic circuit systems, software, hardware, firmware, or any combination thereof, as applicable. Each of the video encoder 28 and the video decoder 48 can be included in one or more encoders or decoders, either of which can be integrated as part of a combined video encoder / decoder (CODEC). Similarly, each of the audio encoder 26 and the audio decoder 46 can be included in one or more encoders or decoders, either of which can be integrated as part of a combined CODEC. An apparatus including the video encoder 28, the video decoder 48, the audio encoder 26, the audio decoder 46, the encapsulation unit 30, the RTP receiving unit 52, and / or the decapsulation unit 50 may include an integrated circuit, a microprocessor, and / or a wireless communication device, such as a cellular phone.

[0040] Client device 40, server device 60, and / or content preparation device 20 may be configured to operate according to the techniques of this disclosure. For purposes of example, this disclosure describes these techniques with respect to client device 40 and server device 60. However, it should be understood that content preparation device 20 may also be configured to perform these techniques as an alternative to or in addition to server device 60.

[0041] The encapsulation unit 30 may form a NAL unit including a header identifying the program to which the NAL unit belongs and a payload, such as audio data, video data, or data describing a transport or program stream to which the NAL unit corresponds. For example, in H.264 / AVC, a NAL unit includes a 1-byte header and a payload of varying size. A NAL unit including video data in its payload may include video data at various levels of granularity. For example, a NAL unit may include a block of video data, a plurality of blocks, a slice of video data, or an entire picture of video data. The encapsulation unit 30 may receive encoded video data in the form of PES packets having elementary streams from the video encoder 28. The encapsulation unit 30 may associate each elementary stream with a corresponding program.

[0042] The encapsulation unit 30 may also assemble an access unit from a plurality of NAL units. Generally speaking, an access unit may include one or more NAL units for representing a frame of video data, and audio data corresponding to the frame (when the audio data is available). An access unit typically includes all NAL units for an output time instance, for example, all audio and video data for a time instance. For example, if each view has a frame rate of 20 frames per second (fps), each time instance may correspond to a time interval of 0.05 seconds. During this time interval, specific frames for all views of the same access unit (same time instance) may be rendered simultaneously. In one example, an access unit may include a decoded picture in a time instance, which may be presented as a primarily decoded picture.

[0043] Thus, an access unit may include all audio and video frames of a common time instance, such as all views corresponding to time X. The present disclosure also refers to the coded pictures of a specific view as "view components". That is, a view component may include coded pictures (or frames) for a specific view at a specific time. Thus, an access unit may be defined as including all view components of a common time instance. The decoding order of access units is not necessarily the same as the output order or display order.

[0044] After the encapsulation unit 30 has assembled the NAL units and / or access units into a video file based on the received data, the encapsulation unit 30 passes the video file to the output interface 32 for output. In some examples, the encapsulation unit 30 may store the video file locally or transmit the video file to a remote server via the output interface 32, rather than directly transmitting the video file to the client device 40. The output interface 32 may include, for example, a transmitter, a transceiver, a device for writing data to a computer-readable medium (such as, for example, an optical drive, a magnetic media drive (e.g., a floppy disk drive)), a universal serial bus (USB) port, a network interface, or other output interface. The output interface 32 outputs the video file to a computer-readable medium, such as, for example, a transmission signal, a magnetic medium, an optical medium, a memory, a flash drive, or other computer-readable medium.

[0045] The network interface 54 may receive NAL units or access units via the network 74 and provide the NAL units or access units to the decapsulation unit 50 via the RTP receiving unit 52. The decapsulation unit 50 may decapsulate the elements of the video file into constituent PES streams, depacketize the PES streams to retrieve the encoded data, and send the encoded data to the audio decoder 46 or the video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream (e.g., as indicated by the PES packet header of the stream). The audio decoder 46 decodes the encoded audio data and transmits the decoded audio data to the audio output 42, while the video decoder 48 decodes the encoded video data and transmits the decoded video data (which may include multiple views of the stream) to the video output 44.

[0046] For the purpose of example, the above technology is described for RTP. However, the technology of the present disclosure can use other protocols for transmitting media data, such as protocols based on HTTP streaming, such as HTTP dynamic adaptive streaming (DASH) or HTTP live streaming (HLS). In HTTP streaming such as HTTP dynamic adaptive streaming (DASH), frequently used operations include HEAD, GET and partial GET. The HEAD operation retrieves the header of the file associated with a given uniform resource locator (URL) or uniform resource name (URN) without retrieving the payload associated with the URL or URN. The GET operation retrieves the entire file associated with a given URL or URN. The partial GET operation receives a byte range as an input parameter and retrieves a continuous number of bytes of the file, wherein the number of bytes corresponds to the received byte range. Therefore, movie fragments can be provided for HTTP streaming, because the partial GET operation can obtain one or more separate movie fragments. In a movie fragment, there can be several track fragments of different tracks. In HTTP streaming, media presentation can be a structured data set accessible to the client. The client can request and download media data information to provide streaming services to users.

[0047] In an example of streaming 3GPP data using HTTP streaming, there may be multiple representations of video and / or audio data for multimedia content. As will be explained below, different representations may correspond to different coding characteristics (e.g., different video coding standard profiles or levels), different coding standards or extensions of coding standards (such as multi-view and / or scalable extensions), or different bit rates. A list of such representations may be defined in a media presentation description (MPD) data structure. Media presentation may correspond to a structured data set accessible to an HTTP streaming client device. An HTTP streaming client device may request and download media data information to provide streaming services to a user of a client device. Media presentation may be described in an MPD data structure (which may include updates to the MPD).

[0048] Media presentation can comprise a sequence of one or more cycles. Each cycle can be extended until the beginning of the next cycle, or in the case of the last cycle, until the end of media presentation. Each cycle can comprise one or more representations for the same media content. Representation can be a version in several alternatively encoded versions of audio, video, timed text or other such data. Representation can be different according to encoding type (for example, bit rate, resolution, and / or the codec for video data and bit rate, language, and / or the codec for audio data). The term represents the part that can be used to refer to the specific cycle of the audio or video data of encoding corresponding to the multimedia content and encoded in a particular way.

[0049] Representations for a particular period may be assigned to a group indicated by an attribute in the MPD that indicates the adaptation set to which the representation belongs. Representations in the same adaptation set are typically viewed as alternatives to each other because client devices may dynamically and seamlessly switch between these representations, for example, to perform bandwidth adaptation. For example, each representation of video data for a particular period may be assigned to the same adaptation set so that any of the representations may be selected for decoding to present media data (such as video data or audio data) for multimedia content for the corresponding period. Media content within a period may be represented by one representation from group 0, if any, or, in some examples, by a combination of at most one representation from each non-zero group. Timing data for each representation of a period may be expressed relative to the start time of the period.

[0050] A representation may include one or more segments. Each representation may include an initialization segment, or each segment of a representation may be self-initializing. When an initialization segment exists, it may contain initialization information for accessing the representation. Generally speaking, an initialization segment does not contain media data. A segment may be uniquely referenced by an identifier such as a uniform resource locator (URL), a uniform resource name (URN), or a uniform resource identifier (URI). The MPD may provide an identifier for each segment. In some examples, the MPD may also provide a byte range in the form of a range attribute, which may correspond to data for a segment within a file that can be accessed by a URL, URN, or URI.

[0051] Different representations can be selected for substantially simultaneously retrieving different types of media data. For example, a client device can select an audio representation, a video representation, and a timed text representation from which to retrieve a segment. In some examples, a client device can select a specific adaptation set for performing bandwidth adaptation. That is, a client device can select an adaptation set comprising a video representation, an adaptation set comprising an audio representation, and / or an adaptation set comprising a timed text. Alternatively, a client device can select an adaptation set for certain types of media (e.g., video), and directly select representations for other types of media (e.g., audio and / or timed text).

[0052] When performing HTTP streaming, the client device 40 may determine configuration data representing the decoding capabilities of the video decoder 48 and the rendering capabilities of the video output 44. The configuration data may also include any or all of the following: a language preference selected by a user of the client device 40, one or more camera viewing angles corresponding to a depth preference set by a user of the client device 40, and / or a hierarchical preference selected by a user of the client device 40. The client device 40 may include, for example, a web browser or a media client configured to submit HTTP GET requests and partial GET requests. The client device 40 may include software instructions executed by one or more processors or processing units (not shown) of the client device 40. In some examples, all or part of the functionality described for the client device 40 may be implemented in hardware, or a combination of hardware, software, and / or firmware, wherein the necessary hardware may be provided to execute instructions for the software or firmware.

[0053] The client device 40 may compare the decoding capabilities and rendering capabilities of the client device 40 with the characteristics of the representation 68 indicated by the information of the manifest file 66. The client device 40 may initially retrieve at least a portion of the manifest file 66 to determine the characteristics of the representation 68. For example, the client device 40 may request a portion of the manifest file 66 that describes the characteristics of one or more adaptation sets. The client device 40 may select a subset of the representations 68 (e.g., an adaptation set) that have characteristics that can be satisfied by the decoding capabilities and rendering capabilities of the client device 40. The client device 40 may then determine a bit rate for the representations in the adaptation set, determine an amount of network bandwidth that is currently available, and retrieve a segment from one of the representations that has a bit rate that can be satisfied by the network bandwidth.

[0054] Generally speaking, a higher bit rate representation can produce a higher quality video playback, while a lower bit rate representation can provide sufficient quality video playback when the available network bandwidth decreases. Therefore, when the available network bandwidth is relatively high, the client device 40 can retrieve data from a relatively high bit rate representation, and when the available network bandwidth is low, the client device 40 can retrieve data from a relatively low bit rate representation. In this way, the client device 40 can stream multimedia data through the network 74 while also adapting to the changing network bandwidth availability of the network 74.

[0055] Additionally or alternatively, client device 40 may be configured to receive data according to a broadcast or multicast network protocol, such as eMBMS or IP multicast. In such an example, client device 40 may submit a request to join a multicast network group associated with particular media content. After joining the multicast group, client device 40 may receive data of the multicast group without issuing further requests to server device 60 or content preparation device 20. When the data of the multicast group is no longer needed, client device 40 may submit a request to leave the multicast group, for example, to stop playback or change the channel to a different multicast group.

[0056] Figure 2 1 is a block diagram illustrating an architecture 100 of a system that can be configured to perform immersive real-time communication (iRTCW) for web real-time communication (WebRTC) according to the technology of the present disclosure. Specifically, the architecture 100 can be used for 5G media streaming (5GMS) using WebRTC. That is, the architecture 100 can be used to perform WebRTC real-time communication over a 5G network connection.

[0057] The architecture 100 can be used to provide WebRTC in various scenarios. As an example, the architecture 100 can be used in conjunction with a 5G network to provide "over the top" (OOT) WebRTC. As another example, a mobile network operator (MNO) can use the architecture 100 to provide trusted WebRTC functionality and / or facilitate WebRTC services. As yet another example, the architecture 100 can provide interoperable WebRTC services. The architecture 100 can also be used in a variety of other scenarios. The architecture 100 provides flexibility through a set of functions and interfaces that can be combined in different ways based on the needs of a specific scenario.

[0058] exist Figure 2 In the example of , the architecture 100 includes a 5G RTC application provider 102, a 5G RTC application function 104, and a user equipment (UE) 150. Generally speaking, the 5G RTC application provider 102 interacts with the functionality of the 5G RTC application function 104 and supplies 5G RTC-aware applications such as network applications 152 to the user equipment 150.

[0059] User equipment 150 may also be referred to as "UE" or "client device". UE 150 may correspond to Figure 1 The user equipment 150 may be, for example, a laptop or desktop computer, a digital camera, a digital recording device, a digital media player, a video gaming device, a video gaming console, a cellular or satellite radio telephone, a video teleconferencing device, etc. In this example, the user equipment 150 includes a network application 152, a local WebRTC application 154, and a media session handler (MSH) 158. The network application 152, the local WebRTC application 154, and the MSH 156 may correspond to Figure 1 The RTP receiving unit 52 of the embodiment of the present invention is connected to the local WebRTC application 154 and the MSH 158. The interface 156 connects the local WebRTC application 154 and the MSH 158. The interface 156 may be referred to as an "RTC-6" interface. The UE 150 and the 5G RTC application provider 102 are connected via an interface 174, which may be referred to as an "RTC-8" interface.

[0060] MSH 158 is a function in UE 150 that provides WebRTC applications (such as network applications 152) access to 5G RTC support functions (such as 5G RTC application functions 104). These functions can be provided through interface 156 (RTC-6 interface) when requested, or transparently provided without directly involving network application 154. For example, MSH 158 can indirectly assist interactive connectivity establishment (ICE) negotiation by providing a Session Traversal Utility (STUN) for Network Address Translation and / or providing a list of Traversal (TURN) server candidates using NAT Relays Around 5G RTC functionality. MSH 158 can also collect Quality of Experience (QoE) metric reports and submit consumption reports. MSH 158 can also provide media configuration recommendations to network application 152 through interface 156 (RTC-6).

[0061] According to "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G Media Streaming (5GMS); Protocol" (Release 17) TS26.512, (March 2022), the UE's media session handler maintains internal attributes as follows:

[0062] Table 12.2.2.2-1: Media session handler parameters

[0063]

[0064] When the local WebRTC application 154 makes a call to a media presentation description (MPD) URL, the MSH 158 may be initiated. During the WebRTC session, the MSH 158 may transmit a consumption report to, for example, the 5G RTC application provider 102. The consumption report may generally indicate the content that has been consumed by the UE 150. The network assistance configuration may represent bit rate recommendations and delivery enhancements from the 5G RTC AF 104. The policy template configuration may represent one or more policies selected from a set of policy templates configured during the provisioning session. The metric report configuration may represent the metric reports to be delivered to the 5G RTC AF 104, such as the content of the metric reports, the delivery frequency of the metric reports, etc.

[0065] Interface 170 (which may be referred to as an "RTC-1" interface) allows a 5G RTC application provider 102 to provide support for provided RTC sessions as a 5G RTC application function 104. Provisioning may cover functionality including quality of service (QoS) for WebRTC sessions, billing provisioning for WebRTC sessions, collection of consumption and QoE metric data related to WebRTC sessions, provision of ICE functionality (such as STUN servers and TURN servers), and / or provision of a WebRTC signaling server (potentially with interoperability with other signaling servers).

[0066] In this example, the 5G RTC application function 104 includes a 5G RTC support application function (AF) 110, a 5G RTC configuration (config) AF 112, a 5G RTC provisioning AF 114, a 5G RTC data channel AF 116, a 5G RTC signaling server AF 118, a 5G RTC interoperability (interop) AF 120, a 5G RTC STUN AF 122, and a 5G RTC TURN AF 124. In this example, the 5G RTC application function 104 may also interoperate with a policy and charging function (PCF) 160, a network exposure function (NEF) 162, and a session management function (SMF) 164.

[0067] Interface 170, which may be referred to as a "provisioning interface," is not necessarily relevant to all collaboration scenarios and may provide some of the 5G support functionality without provision by an application provider.

[0068] Interface 172 (which may be referred to as an "RTC-5" interface) is an interface between the MSH 158 and the 5G RTC application function 104. Interface 172 may be used to communicate configuration information from the 5G RTC application function 104 to the MSH 158 and request support for a started / ongoing WebRTC session. The configuration information may include static information such as recommendations for media configuration, configuration of STUN and TURN server locations, configuration regarding consumption and QoE reporting, or discovery information for WebRTC signaling and data channel servers and their capabilities.

[0069] The MSH 158 may provide supporting functionality, such as notifying the 5G RTC application function 104 or the network application 152 about a WebRTC session and its status, requesting a QoS allocation for a started or modified WebRTC session, receiving notifications about changes in QoS allocations for an ongoing WebRTC session, or receiving, updating, or exchanging information about a WebRTC session with a 5G RTC STUN / TURN / signaling server, e.g., to identify the WebRTC session and associate it with a QoS template.

[0070] In some examples, the 5G functionality that provides application functionality to WebRTC applications (including 5G RTC data channel AF 116, 5G RTC signaling server AF 118, 5G RTC interoperation AF 120, 5G RTC STUN AF 122, and 5G RTC TURNAF 124) may alternatively be provided by an application server (5G RTC AS) instead of an AF. The 5G RTC AS may then use a dedicated RTC-3 interface to request configuration and network support for an ongoing WebRTC session from the 5G RTC AF.

[0071] The functionality attributed to the 5G RTC application provider 102, the 5G RTC application function 104, and the UE 150 may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software or firmware, a memory may be provided for storing instructions that may be executed by one or more processors implemented in circuits. The processor may include one or more of a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), discrete logic circuits, or any combination thereof.

[0072] In this way, UE 150 represents an example of a device for exchanging media data, the device comprising: a memory configured to store media data; and one or more processors implemented in circuits and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange media data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0073] Figure 3 is a call flow diagram illustrating an example method for initiating a WebRTC media session according to the techniques of this disclosure.In some examples, a 5G system for WebRTC sessions can provide integrated support by providing 5G RTC STUN functionality.

[0074] 5G RTC STUN AF is a STUN server (compatible with RFC8489). In addition, the 5G RTC STUN AF server provides 5G functionality to support WebRTC sessions. The STUN server receives binding requests as part of the ICE negotiation. These requests allow the STUN server to discover the public IP address and port number of the connection, the so-called reflexive transport address. The request and response may contain STUN attributes, which may be marked as required to be understood or optional to understand. A STUN server that is not configured to interpret required to be understood attributes may reply with an error message. IANA maintains a registry of STUN attributes.

[0075] The present disclosure describes additional STUN attributes that can be used to trigger 5G support for WebRTC applications. These attributes can allow the 5G RTC STUN server to request, for example, QoS allocation and billing for media connections. The following attributes are examples of additional STUN attributes, which can be understood as optional attributes: 3GPP-PRIVATE-ADDRESS: protocol family indicator, IP address, and port number corresponding to the private transport address seen by the UE; 3GPP-QOS: an indication of the QoS attributes associated with the connection associated with the request, which may include an average bit rate, maximum bit rate, maximum delay, and maximum packet loss rate (PLR) indicator; and 3GPP-CODEC: represents the codec mime type and codec parameters that describe the codec to be used for the connection, and multiple values ​​can be provided.

[0076] 5G RTC STUN servers MAY support these attributes. The 5G RTC STUN server MAY use this information in a successful binding to request QoS allocation and charging policy. The 5G RTC STUN server MAY also respond with recommendations regarding target QoS parameters and / or recommended codecs using STUN attributes.

[0077] for Figure 3 For example, application service providers (ASPs) that provide better 5G support to their WebRTC-based applications (e.g., Figure 2 The 5G RTC application provider 102) creates a provisioning session (200) with the 5G RTC provisioning AF 114. This step is optional, and the mobile network operator (MNO) may decide to provide support for WebRTC sessions without an associated provisioning session.

[0078] The 5G RTC provisioning AF 114 may then share the QoS and media configuration templates (202) with all associated 5G RTC AFs 104. This may be done, for example, by storing this information in a unified data management function (UDF).

[0079] The 5G RTC Configuration AF 112 may then transmit the WebRTC configuration including the STUN and TURN server lists to the MSH 158 as part of the service access information (204).

[0080] Web application 152 may obtain a list of pre-configured STUN and TURN servers from a local configuration, for example, via MSH 158 (206). The configuration may indicate for each server whether the server is 5G RTC enabled.

[0081] The network application 152 may then submit a bind request with additional attributes to the 5G RTC STUN AF 122 server to trigger ICE negotiation (208).

[0082] The 5G RTC STUN AF 122 retrieves the associated QoS template and media configuration (210).

[0083] The 5G RTC STUN AF 122 creates a binding response and transmits the additional information along with the address binding back to the network application 152 (212).

[0084] The network application 152 updates the offer / answer session description protocol (SDP) based on the received STUN information (214). The WebRTC media session can then be started (216). That is, the network application 152 can transmit and / or receive media data via the WebRTC media session.

[0085] To configure a WebRTC session, MSH 158 may receive a list of 5G RTC STUN and TURN servers provided by the MNO for 5G system integration for WebRTC sessions. MSH 158 may also receive recommendations for QoS templates for WebRTC sessions. MSH makes this information available to network application 152 via interface 156 (i.e., RTC-6 interface).

[0086] The format of the information can be as follows:

[0087]

[0088] For a web application such as web application 152, configuration information may be accessed through a standardized W3C API such as an index database API or a file API.

[0089] The 5G RTC STUN server can use the N5 interface or the N33 interface to request QoS allocation for the associated STUN binding. Upon determining the 3-tuple (public IP address, port number, and protocol) for the connection, the 5G RTC STUN server can call the Nnef_AFsessionWithQoS or Npcf_PolicyAuthorization method to request QoS for the identified QoS flow.

[0090] Figure 4 is a flow chart illustrating an example method for establishing a WebRTC session in a radio access network according to the techniques of this disclosure. Figure 2 UE 150 to illustrate Figure 4 However, other devices (such as Figure 1 The client device 40) can perform this method or a similar method.

[0091] As described above, UE 150 may execute MSH 158 to communicate with one or more application functions such as Figure 2 140). The UE 150 may also execute a local WebRTC application 154 to perform WebRTC operations, such as transmitting and receiving media data via the WebRTC session. Specifically, the UE 150 may execute the MSH 158 to receive interactive connectivity establishment (ICE) configuration information (250) for the WebRTC session. The ICE configuration information may include a list of ICE candidates and, for each of the ICE candidates, a type of the ICE candidate (e.g., STUN or TURN), a URL for accessing the ICE candidate, and an indication of whether the ICE candidate is 5G enabled.

[0092] Using the received ICE configuration information, MSH 158 may select one of the 5G RTC-enabled ICE candidates (252). MSH 158 may then transmit a binding request (254) to the selected ICE candidate. The binding request may include additional attributes that trigger ICE negotiation. These attributes may include, for example, 3GPP dedicated address data including a protocol family indicator, an IP address, and a port number corresponding to a dedicated transport address seen by UE 150. These attributes may also include 3GPP quality of service (QoS) data indicating QoS attributes associated with the requested connection. QoS attributes may include an average bit rate, a maximum bit rate, a maximum delay, and a packet loss rate (PLR) indication. These attributes may also include 3GPP codec data indicating one or more CODEC mime types and codec parameters describing the codec to be used for the connection.

[0093] The MSH 158 may then receive a binding response from the ICE candidate, wherein the binding response includes a QoS template and media configuration data (256). The media configuration data may include a list of media configuration recommendations and, for each media recommendation, include the type (e.g., whether the media is audio, video, text, etc.), the codec configuration of the media, the recommended average bit rate of the media, and the recommended peak or maximum bit rate of the media. The MSH 158 may then use the received information to update the session description offer or answer (258) and establish a WebRTC session (260). The network application 152 may then participate in the virtual scene, transmitting and receiving application layer data via the local WebRTC application 154, which may encapsulate and decapsulate the WebRTC data into various formats for the network application 152. In this way, the network application 152 may exchange media data via the WebRTC session (262).

[0094] therefore, Figure 4 The method represents an example of the following method, including: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions including one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receiving a network application from the application provider device; and exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0095] Examples of some of the techniques of this disclosure are summarized in the following clauses:

[0096] Item 1: A device for retrieving media data, the device comprising: a memory configured to store media data; and one or more processors implemented in circuits and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0097] Clause 2: The apparatus of clause 1, wherein the one or more processors are further configured to participate in a Web Real-Time Communication (WebRTC) session using the one or more application functions to transmit or receive the media data via the WebRTC session.

[0098] Clause 3: The apparatus of any of clauses 1 and 2, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0099] Clause 4: A device according to any one of clauses 1 to 3, wherein the one or more processors are further configured to: receive WebRTC configuration data from a configuration application function; determine interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submit a binding request to a Session Traversal Utilities for Network Address Translation (STUN) server using the ICE and media configuration parameters; receive binding information including quality of service (QoS) and codec data in response to the binding request; update a Session Description Protocol (SDP) offer or response based on the received binding information; and initiate a WebRTC media session based on the updated SDP offer or response.

[0100] Clause 5: An application provider device, the application provider device comprising: a memory configured to store media data; and one or more processors implemented in a circuit and configured to: provide one or more application functions, the one or more application functions including one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; provide a network application to a user equipment (UE) device; and exchange data between the one or more application functions and the UE device.

[0101] Clause 6: An application provider device according to clause 5, wherein the one or more processors are further configured to use the one or more application functions to participate in a Web Real-Time Communication (WebRTC) session to transmit or receive the media data via the WebRTC session.

[0102] Clause 7: The apparatus of any of clauses 5 and 6, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0103] Clause 8: An application provider device according to any one of clauses 5 to 7, wherein the one or more processors are further configured to: share one or more quality of service (QoS) templates and Session Traversal Utilities for Network Address Translation (STUN) server configuration data; transmit WebRTC configuration data to the UE device based on the QoS template and STUN server configuration data; receive a binding request with configuration parameters from the UE device; verify the binding request using the QoS template and STUN server configuration data; and transmit binding information including QoS and codec recommendations to a client device to initiate a WebRTC session.

[0104] Clause 9: A method for retrieving media data, the method comprising: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receiving a network application from the application provider device; and exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0105] Clause 10: The method of clause 9, further comprising participating in a Web Real-Time Communication (WebRTC) session using the one or more application functions to transmit or receive the media data via the WebRTC session.

[0106] Clause 11: The method of any one of clauses 9 and 10, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0107] Clause 12: According to the method described in any one of clauses 9 to 11, the method further includes: receiving WebRTC configuration data from a configuration application function; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to a Session Traversal Utilities for Network Address Translation (STUN) server using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a Session Description Protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0108] Clause 13: A method comprising: providing one or more application functions, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; providing a network application to a user equipment (UE) device; and exchanging data between the one or more application functions and the UE device.

[0109] Clause 14: The method of clause 13, further comprising participating in a Web Real-Time Communication (WebRTC) session using the one or more application functions to transmit or receive the media data via the WebRTC session.

[0110] Clause 15: The method of any one of clauses 13 and 14, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0111] Clause 16: A method according to any one of clauses 13 to 15, the method further comprising: sharing one or more quality of service (QoS) templates and Session Traversal Utilities for Network Address Translation (STUN) server configuration data; transmitting WebRTC configuration data to the UE device based on the QoS template and the STUN server configuration data; receiving a binding request with configuration parameters from the UE device; verifying the binding request using the QoS template and the STUN server configuration data; and transmitting binding information including QoS and codec recommendations to a client device to initiate a WebRTC session.

[0112] Clause 17: A computer readable storage medium having stored thereon instructions which, when executed, cause a processor to perform the method of any one of clauses 9 to 16.

[0113] Clause 18: A device comprising: means for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; means for receiving a network application from the application provider device; and means for exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0114] Clause 19: A device comprising: means for providing one or more application functions, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; means for providing a network application to a user equipment (UE) device; and means for exchanging data between the one or more application functions and the UE device.

[0115] Clause 20: A device for exchanging media data, the device comprising: a memory configured to store media data; and one or more processors implemented in circuits and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange media data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0116] Clause 21: A device according to Clause 20, wherein in order to exchange the media data between the one or more application functions, the MSH and the network application, the one or more processors are configured to transmit or receive the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0117] Clause 22: The apparatus of any one of clauses 20 and 21, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0118] Clause 23: A device according to any one of clauses 20 to 22, wherein the one or more processors are further configured to: receive Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determine interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submit a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receive binding information including quality of service (QoS) and codec data in response to the binding request; update a session description protocol (SDP) offer or response based on the received binding information; and initiate a WebRTC media session based on the updated SDP offer or response.

[0119] Clause 24: A device according to clause 23, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0120] Clause 25: An apparatus according to any one of clauses 20 to 24, wherein the MSH is configured to receive a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0121] Clause 26: A method for exchanging media data, the method comprising: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receiving a network application from the application provider device; and exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0122] Clause 27: The method of clause 26, wherein exchanging the media data between the one or more application functions, the MSH, and the web application comprises transmitting or receiving the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0123] Clause 28: The method of any of clauses 26 and 27, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0124] Clause 29: The method according to any one of clauses 26 to 28, further comprising: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining Interactive Connectivity Establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a Session Description Protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0125] Clause 30: A method according to clause 29, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0126] Clause 31: The method according to any one of clauses 26 to 30 further includes receiving, by the MSH, a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate, and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0127] Clause 32: A computer-readable storage medium having instructions stored thereon, which when executed cause a processor to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions including one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange media data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0128] Clause 33: A computer-readable storage medium according to clause 32, wherein the instructions causing the processor to exchange the media data between the one or more application functions, the MSH and the network application include instructions causing the processor to transmit or receive the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0129] Clause 34: The computer-readable storage medium of any one of clauses 32 and 33, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0130] Clause 35: A computer-readable storage medium according to any one of clauses 32 to 34, wherein the computer-readable storage medium further comprises instructions for causing the processor to perform the following items: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a session description protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0131] Clause 36: A computer-readable storage medium as described in clause 35, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0132] Clause 37: A computer-readable storage medium according to any one of clauses 32 to 36, wherein the computer-readable storage medium further comprises instructions for causing the processor to execute the MSH to perform the following items: receiving a list of media configuration recommendations to create a session description protocol (SDP) offer or response, wherein the list of media configuration recommendations comprises data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0133] Clause 38: A device for exchanging media data, the device comprising: a component for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; a component for receiving a network application from the application provider device; and a component for exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0134] Clause 39: The apparatus of clause 38, wherein the means for exchanging the media data between the one or more application functions, the MSH and the network application comprises means for transmitting or receiving the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0135] Clause 40: The apparatus of any one of clauses 38 and 39, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0136] Clause 41: A device according to any one of clauses 38 to 40, wherein the device further comprises: a component for receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; a component for determining Interactive Connectivity Establishment (ICE) and media configuration parameters from the WebRTC configuration data; a component for submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; a component for receiving binding information including quality of service (QoS) and codec data in response to the binding request; a component for updating a Session Description Protocol (SDP) offer or response based on the received binding information; and a component for initiating a WebRTC media session based on the updated SDP offer or response.

[0137] Clause 42: A device according to clause 41, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0138] Clause 43: An apparatus according to any one of clauses 38 to 42, the apparatus further comprising a component for executing the MSH to receive a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or response, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0139] Clause 44: A device for exchanging media data, the device comprising: a memory configured to store media data; and one or more processors implemented in circuits and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange media data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0140] Clause 45: A device according to clause 44, wherein, in order to exchange the media data between the one or more application functions, the MSH and the network application, the one or more processors are configured to transmit or receive the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0141] Clause 46: The apparatus of clause 44, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0142] Clause 47: A device according to clause 44, wherein the one or more processors are further configured to: receive Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determine interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submit a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receive binding information including quality of service (QoS) and codec data in response to the binding request; update a session description protocol (SDP) offer or response based on the received binding information; and initiate a WebRTC media session based on the updated SDP offer or response.

[0143] Clause 48: A device according to clause 47, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0144] Clause 49: An apparatus according to clause 44, wherein the MSH is configured to receive a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate, and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0145] Clause 50: A method for exchanging media data, the method comprising: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receiving a network application from the application provider device; and exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0146] Clause 51: The method of clause 50, wherein exchanging the media data between the one or more application functions, the MSH, and the web application comprises transmitting or receiving the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0147] Clause 52: The method of clause 50, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0148] Clause 53: According to the method described in Clause 50, the method also includes: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connection establishment (ICE) and media configuration parameters from the WebRTC configuration data; using the ICE and media configuration parameters to submit a binding request to one of the STUN server application function or the TURN server application function; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a session description protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0149] Clause 54: A method according to clause 53, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0150] Clause 55: The method according to clause 50 further includes receiving, by the MSH, a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate, and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0151] Clause 56: A computer-readable storage medium having instructions stored thereon, which when executed cause a processor to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; receive a network application from the application provider device; and exchange media data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0152] Clause 57: A computer-readable storage medium according to clause 56, wherein the instructions causing the processor to exchange the media data between the one or more application functions, the MSH and the network application include instructions causing the processor to transmit or receive the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0153] Clause 58: The computer-readable storage medium of clause 56, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0154] Clause 59: A computer-readable storage medium according to clause 56, wherein the computer-readable storage medium further comprises instructions for causing the processor to perform the following items: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a session description protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0155] Clause 60: A computer-readable storage medium as described in clause 59, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0156] Clause 61: A device according to clause 56, wherein the device further comprises instructions that cause the processor to execute the MSN to perform the following items: receiving a list of media configuration recommendations to create a session description protocol (SDP) offer or response, wherein the list of media configuration recommendations comprises data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0157] Clause 62: A device for exchanging media data, the device comprising: a component for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, the one or more application functions comprising one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function; a component for receiving a network application from the application provider device; and a component for exchanging data between the one or more application functions provided by the application provider device, the MSH, and the network application.

[0158] Clause 63: The apparatus of clause 62, wherein the means for exchanging the media data between the one or more application functions, the MSH and the network application comprises means for transmitting or receiving the media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0159] Clause 64: The apparatus of clause 62, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0160] Clause 65: The device according to clause 62 further includes: a component for receiving web real-time communication (WebRTC) configuration data from a configuration application function among the one or more application functions; a component for determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; a component for submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; a component for receiving binding information including quality of service (QoS) and codec data in response to the binding request; a component for updating a session description protocol (SDP) offer or response based on the received binding information; and a component for initiating a WebRTC media session based on the updated SDP offer or response.

[0161] Clause 66: A device according to clause 65, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0162] Clause 67: The apparatus of clause 62, further comprising a component for executing the MSH to receive a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0163] Clause 68: A device for exchanging media data, the device comprising: a memory configured to store media data; and one or more processors implemented in circuits and configured to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device; and execute an application to: retrieve configuration information related to Web Real-Time Communication (WebRTC) from the MSH; and use the configuration information to establish a WebRTC session and exchange media data via the WebRTC session.

[0164] Clause 69: An apparatus according to clause 68, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

[0165] Clause 70: The apparatus of clause 68, wherein the one or more application functions include one or more of a policy charging function or a session management function.

[0166] Clause 71: A device according to clause 68, wherein the one or more processors are further configured to: receive Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determine interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submit a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receive binding information including quality of service (QoS) and codec data in response to the binding request; update a session description protocol (SDP) offer or response based on the received binding information; and initiate a WebRTC media session based on the updated SDP offer or response.

[0167] Clause 72: A device according to clause 71, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0168] Clause 73: The apparatus of clause 71, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request a QoS allocation from a policy application function.

[0169] Clause 74: An apparatus according to clause 68, wherein the MSH is configured to receive a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate, and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0170] Clause 75: A method for exchanging media data, the method comprising: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; executing the application to retrieve configuration information related to Web Real-Time Communications (WebRTC) from the MSH; and executing the application to use the configuration information to establish a WebRTC session and exchange media data via the WebRTC session.

[0171] Clause 76: A method according to clause 75, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

[0172] Clause 77: The method of clause 75, wherein the one or more application functions include one or more of a policy charging function or a session management function.

[0173] Clause 78: According to the method described in Clause 75, the method also includes: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connection establishment (ICE) and media configuration parameters from the WebRTC configuration data; using the ICE and media configuration parameters to submit a binding request to one of the STUN server application function or the TURN server application function; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a session description protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0174] Clause 79: A method according to clause 78, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0175] Clause 80: The method of clause 78, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request a QoS allocation from a policy application function.

[0176] Clause 81: The method according to clause 75 further includes receiving, by the MSH, a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations including data representing a media type, codec, average bit rate, and maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0177] Clause 82: A computer-readable storage medium having stored thereon instructions which, when executed, cause a processor to: execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device; execute an application to.

[0178] Clause 83: A computer-readable storage medium according to clause 82, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

[0179] Clause 84: The computer-readable storage medium of clause 82, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

[0180] Clause 85: A computer-readable storage medium according to clause 82, wherein the computer-readable storage medium further comprises instructions for causing the processor to perform the following items: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a session description protocol (SDP) offer or response based on the received binding information; and initiating a WebRTC media session based on the updated SDP offer or response.

[0181] Clause 86: A computer-readable storage medium as described in clause 85, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0182] Clause 87: A computer-readable storage medium according to clause 82, wherein the computer-readable storage medium further comprises instructions that cause the processor to execute the MSH to perform the following items: receiving a list of media configuration recommendations to create a session description protocol (SDP) offer or response, wherein the list of media configuration recommendations comprises data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0183] Clause 88: A device for exchanging media data, the device comprising: a component for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; a component for executing an application to retrieve configuration information related to web real-time communications (WebRTC) from the MSH; and a component for exchanging data between the one or more application functions provided by the application provider device, the MSH and the web application.

[0184] Clause 89: An apparatus according to clause 88, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

[0185] Clause 90: The apparatus of clause 88, wherein the one or more application functions include one or more of a policy charging function, a network exposure function, or a session management function.

[0186] Clause 91: A device according to clause 88, wherein the device further comprises: a component for receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; a component for determining Interactive Connectivity Establishment (ICE) and media configuration parameters from the WebRTC configuration data; a component for submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; a component for receiving binding information including quality of service (QoS) and codec data in response to the binding request; a component for updating a Session Description Protocol (SDP) offer or response based on the received binding information; and a component for initiating a WebRTC media session based on the updated SDP offer or response.

[0187] Clause 92: A device according to clause 91, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating the type of the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

[0188] Clause 93: The apparatus of clause 91, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request a QoS allocation from a policy application function.

[0189] Clause 94: The apparatus of clause 88, further comprising a component for executing the MSH to receive a list of media configuration recommendations to create a session description protocol (SDP) offer or response, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each media configuration recommendation in the media configuration recommendations.

[0190] In one or more examples, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function can be stored as one or more instructions or codes on a computer-readable medium or sent via a computer-readable medium 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, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium can generally correspond to (1) a non-transient tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium can be any available medium that can be accessed by one or more computers or one or more processors to extract instructions, codes, and / or data structures for implementing the technology described in this disclosure. A computer program product may include a computer-readable medium.

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

[0192] 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 logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein may refer to any of the above structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. In addition, these techniques may be fully implemented in one or more circuits or logic elements.

[0193] The techniques of the present disclosure may be implemented in a 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 are described in the present disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require implementation by different hardware units. Specifically, as described above, the various units may be combined in a codec hardware unit, or the various units may be provided by a collection of interoperable hardware units (including one or more processors as described above) in combination with appropriate software and / or firmware.

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

Claims

1. A device for exchanging media data, the device comprising: a memory configured to store media data; and One or more processors implemented in circuitry and configured to: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; and Execute the application to: retrieving configuration information related to Web Real-Time Communications (WebRTC) from the MSH; as well as A WebRTC session is established using the configuration information, and media data is exchanged via the WebRTC session.

2. The device of claim 1, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function. 3 . The device of claim 1 , wherein the one or more application functions include one or more of a policy charging function or a session management function.

4. The apparatus of claim 1 , wherein the one or more processors are further configured to: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a Session Description Protocol (SDP) offer or response according to the received binding information; as well as Initiate a WebRTC media session based on the updated SDP offer or answer.

5. The apparatus of claim 4 , wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and, for each of the ICE server application functions, data indicating a type of the ICE server application function, a URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

6. The apparatus of claim 4, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request QoS allocation from a policy application function.

7. The apparatus of claim 1 , wherein the MSH is configured to receive a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each of the media configuration recommendations.

8. A method for exchanging media data, the method comprising: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; executing an application to retrieve configuration information related to WebRTC from the MSH; as well as The application is executed to establish a WebRTC session using the configuration information and to exchange media data via the WebRTC session.

9. The method of claim 8, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

10. The method of claim 8, wherein the one or more application functions include one or more of a policy charging function or a session management function.

11. The method according to claim 8, further comprising: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a Session Description Protocol (SDP) offer or response according to the received binding information; as well as Initiate a WebRTC media session based on the updated SDP offer or answer.

12. The method of claim 11 , wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and for each of the ICE server application functions, data indicating a type of the ICE server application function, a URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

13. The method of claim 11, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request QoS allocation from a policy application function.

14. The method of claim 8, further comprising receiving, by the MSH, a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each of the media configuration recommendations.

15. A computer-readable storage medium having stored thereon instructions which, when executed, cause a processor to: executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; executing an application to retrieve configuration information related to Web Real-Time Communications (WebRTC) from the MSH; and The application is executed to establish a WebRTC session using the configuration information and to exchange media data via the WebRTC session.

16. A computer-readable storage medium according to claim 15, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

17. The computer-readable storage medium of claim 15, wherein the one or more application functions further comprise one or more of a policy charging function, a network exposure function, or a session management function.

18. The computer-readable storage medium of claim 15, further comprising instructions for causing the processor to: receiving Web Real-Time Communication (WebRTC) configuration data from a configuration application function among the one or more application functions; determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; receiving binding information including quality of service (QoS) and codec data in response to the binding request; updating a Session Description Protocol (SDP) offer or response according to the received binding information; as well as Initiate a WebRTC media session based on the updated SDP offer or answer.

19. The computer-readable storage medium of claim 18, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and for each of the ICE server application functions, data indicating a type of the ICE server application function, a URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

20. The computer-readable storage medium of claim 15, further comprising instructions that cause the processor to execute the MSH to perform the following: receive a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or response, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each of the media configuration recommendations.

21. A device for exchanging media data, the device comprising: means for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device; means for executing an application to retrieve configuration information related to Web Real-Time Communications (WebRTC) from the MSH; as well as Means for exchanging data between the one or more application functions provided by the application provider device, the MSH and a network application.

22. The apparatus of claim 21, wherein the one or more application functions include one or more of a support application function, a configuration application function, a provisioning application function, a channel application function, a signaling server application function, an interoperability application function, a Session Traversal Utilities for Network Address Translation (STUN) application function, or a Traversal Using Relays Around NAT (TURN) application function.

23. The apparatus of claim 21, wherein the one or more application functions include one or more of a policy charging function, a network exposure function, or a session management function.

24. The device according to claim 21, further comprising: means for receiving Web Real-Time Communications (WebRTC) configuration data from a configuration application function of the one or more application functions; means for determining interactive connectivity establishment (ICE) and media configuration parameters from the WebRTC configuration data; means for submitting a binding request to one of a STUN server application function or a TURN server application function using the ICE and media configuration parameters; means for receiving binding information including quality of service (QoS) and codec data in response to the binding request; means for updating a Session Description Protocol (SDP) offer or answer based on the received binding information; as well as Means for initiating a WebRTC media session based on an updated SDP offer or answer.

25. The apparatus of claim 24, wherein the ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation and, for each of the ICE server application functions, data indicating a type of the ICE server application function, a URL of the ICE server application function, and whether the ICE server application function is 5G-RTC enabled.

26. The apparatus of claim 24, wherein the binding request is configured to instruct the one of the STUN server application function or the TURN server application function to request QoS allocation from a policy application function.

27. The apparatus of claim 21, further comprising means for executing the MSH to receive a list of media configuration recommendations to create a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations comprising data representing a media type, a codec, an average bit rate, and a maximum bit rate for each of the media configuration recommendations.