5G Support for WebRTC

Abstract

Exemplary devices for exchanging media data include a memory configured to store media data and one or more processors implemented within a circuitry, where the one or more processors execute a Media Session Handler (MSH) to interact with one or more application functions provided by an application provider device, where 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 Relay-using NAT Traversal (TURN) application function, receive a web application from the application provider device, and are configured to exchange media data among the one or more application functions provided by the application provider device, the MSH, and the web application.

Description

Technical Field

[0001]

[0001] This application claims priority to U.S. Patent Application No. 18 / 310,128, filed May 1, 2023, U.S. Provisional Patent Application No. 63 / 484,568, filed Feb. 13, 2023, and U.S. Provisional Patent Application No. 63 / 364,184, filed May 4, 2022, the entire contents of each of which are incorporated herein by reference. U.S. Patent Application No. 18 / 310,128, filed May 1, 2023, claims the benefit of U.S. Provisional Patent Application No. 63 / 484,568, filed Feb. 13, 2023, and U.S. Provisional Patent Application No. 63 / 364,184, filed May 4, 2022.

[0002]

[0002] This disclosure relates to the storage and transfer of encoded video data.

Background Art

[0003]

[0003] Digital video capabilities can 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 game devices, video game consoles, cellular or satellite radiotelephones, video conferencing devices, and the like. Digital video devices implement video compression techniques such as those 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 those described in extensions to such standards, to more efficiently transmit and receive digital video information.

[0004]

[0004] Video compression techniques perform spatial prediction and / or temporal prediction to reduce or eliminate redundancy inherent in a video sequence. In the case of block-based video coding, a video frame or slice may be partitioned into macroblocks. Each macroblock may be further partitioned. Macroblocks in an intra-coded (I) frame or slice are encoded using spatial prediction with respect to neighboring macroblocks. Macroblocks in an inter-coded (P or B) frame or slice may use spatial prediction with respect to neighboring macroblocks in the same frame or slice or temporal prediction with respect to other reference frames.

[0005]

[0005] After the video data is encoded, the video data may be packetized for transmission or storage. The video data may be assembled into a video file conforming to any of various standards, such as an International Organization for Standardization (ISO) base media file format such as AVC and its extensions.

Summary of the Invention

[0006]

[0006] Generally, the present disclosure describes techniques for initiating a Web Real-time Communication (WebRTC) session for exchanging media data, including, for example, audio, image, and / or video data. The WebRTC session can be initiated within a 5G communication system. WebRTC can be used to exchange media data, such as media data for an extended reality (XR) session, including an augmented reality (AR), mixed reality (MR), or virtual reality (VR) communication session that includes audio and video data along with XR data. A user equipment (UE) involved in a WebRTC session can include a media session handler (MSH) that negotiates with one or more application functions (AFs) of an application server. Further, the UE can retrieve a web application from an application provider (AP) using the MSH. The web application can be configured to participate in an XR session, while a native WebRTC application can be configured to transmit and receive data according to WebRTC via the MSH.

[0007]

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

[0008]

[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 an application to extract configuration information related to Web Real-Time Communication (WebRTC) from the MSH, and using the configuration information to establish a WebRTC session and execute an application to exchange media data via the WebRTC session.

[0009]

[0009] In another example, a computer-readable storage medium stores instructions 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 extract configuration information related to Web Real-Time Communication (WebRTC) from the MSH, use the configuration information to establish a WebRTC session, and execute an application to exchange media data via the WebRTC session.

[0010]

[0010] In another example, a device for exchanging media data includes 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 extract configuration information related to web real-time communication (WebRTC) from the MSH, and means for exchanging data between one or more application functions provided by the application provider device, the MSH, and a web application.

[0011]

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

Brief Description of the Drawings

[0012]

Figure 1

[0012] FIG. is a block diagram showing an exemplary system implementing a technique for streaming media data over a network.

Figure 2

[0013] FIG. is a block diagram of an architecture 100 for a system that can be configured to perform immersive real-time communication for Web Real-Time Communication (iRTCW) for web real-time communication (WebRTC) according to the techniques of the present disclosure.

Figure 3

[0014] FIG. is a call flow diagram showing an exemplary method for initiating a WebRTC media session according to the techniques of the present disclosure.

Figure 4

[0015] FIG. is a flowchart showing an exemplary method for establishing a WebRTC session within a wireless access network according to the techniques of the present disclosure.

Mode for Carrying Out the Invention

[0013]

[0016] Generally, the present disclosure describes techniques for providing support for Web Real-Time Communication (WebRTC) in a radio access network (RAN), such as a 5G network. 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, as part of a WebRTC session, along with audio and / or video data. For example, the UE may transmit user avatar information representing the appearance of the user within a virtual scene, user posture and / or movement information, actions performed by the user, or 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. Thus, for example, multiple UEs may be involved in a WebRTC session for a virtual remote conference, video game, or other such scenario within a virtual scene.

[0014]

[0017] According to the techniques of the present disclosure, a UE may include a Media Session Handler (MSH) and a native WebRTC application. The WebRTC application may be configured to transmit and receive WebRTC session data via the MSH, while the MSH may transmit and receive data using one or more application functions (AFs) of a reliable RTC AF server. To determine the RTC AF server, the MSH may first perform an Interactive Connectivity Establishment (ICE) negotiation. The ICE negotiation may generally include taking out a list of ICE candidates and selecting one of the ICE candidates to be used for the WebRTC session. The ICE candidates may be, for example, Session Traversal Utilities for Network Address Translation (STUN) and / or Traversal Using Relay around NAT (TURN) server candidates that provide 5G RTC functionality. The MSH may also take out media configuration recommendations. The MSH may provide data representing the ICE candidates and the media configuration recommendations to the web application.

[0015]

[0018] The web application may construct a request (or a response to the request) for the WebRTC session and transmit the request to one of the ICE candidates. After one of the ICE candidates verifies the validity of the request, the UE may receive, from one of the ICE candidates, one binding information, as well as quality of service (QoS) and codec recommendations. 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, for example, a WebRTC media session with one or more other UEs and / or a media server.

[0016]

[0019] FIG. 1 is a block diagram showing an exemplary system 10 that implements techniques for streaming media data over a network. In this example, system 10 includes a content preparation device 20, a server device 60, and a client device 40. The client device 40 and the server device 60 are communicatively coupled by a network 74 that may include the Internet. In some examples, the content preparation device 20 and the server device 60 may also be coupled by the network 74 or another network, or may be communicatively coupled directly. In some examples, the content preparation device 20 and the server device 60 may include the same device.

[0017]

[0020] In the example of FIG. 1, the content preparation device 20 includes an audio source 22 and a video source 24. The audio source 22 may include, for example, a microphone that generates an electrical signal representing captured audio data to be encoded by an audio encoder 26. Alternatively, the audio source 22 may comprise a storage medium storing previously recorded audio data, an audio data generator such as a computerized synthesizer, or any other source of audio data. The video source 24 may include a video camera that generates video data to be encoded by a 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. The content preparation device 20 is not necessarily communicatively coupled to the server device 60 in all examples, but may store multimedia content on a separate medium that can be read by the server device 60.

[0018]

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

[0019]

[0022] An audio frame corresponding to a video frame is generally an audio frame that includes audio data captured (or generated) by the audio source 22 simultaneously with video data captured (or generated) by the video source 24 included within the video frame. For example, while a speaking participant is generally generating audio data by speaking, the audio source 22 captures the audio data, and the video source 24 simultaneously captures video data of the speaking participant, i.e., while the audio source 22 is capturing the audio data. Thus, an audio frame may correspond temporally to one or more specific video frames. Thus, an audio frame corresponding to a video frame generally corresponds to a situation where audio data and video data are captured simultaneously, and for that situation, the audio frame and the video frame each include audio data and video data captured simultaneously.

[0020]

[0023] In some examples, the audio encoder 26 can encode a timestamp in each encoded audio frame that represents the time at which the audio data of the encoded audio frame was recorded. Similarly, the video encoder 28 can encode a timestamp in each encoded video frame that represents the time at which the video data of the encoded video frame was recorded. In such examples, the audio frame corresponding to the video frame can include an audio frame containing a timestamp and a video frame containing the same timestamp. The content preparation device 20 can include an internal clock that the audio encoder 26 and / or the video encoder 28 may use to generate timestamps, or an internal clock that the audio source 22 and the video source 24 may use to associate the audio data and the video data with timestamps, respectively.

[0021]

[0024] In some examples, the audio source 22 may send data corresponding to the time at which the audio data was recorded to the audio encoder 26, and the video source 24 can send data corresponding to the time at which the video data was recorded to the video encoder 28. In some examples, the audio encoder 26 does not necessarily indicate the absolute time at which the audio data was recorded in the encoded audio data, but may encode a sequence identifier to indicate the relative chronological order of the encoded audio data. Similarly, the video encoder 28 may also use a sequence identifier to indicate the relative chronological order of the encoded video data. Similarly, in some examples, the sequence identifier may be mapped with or correlated with the timestamp.

[0022]

[0025] The audio encoder 26 generally generates a stream of encoded audio data, while the video encoder 28 generates a stream of encoded video data. Each individual stream of data (whether audio or video) may be referred to as an elementary stream. An elementary stream is a single digitally encoded (and possibly compressed) component of a media presentation. For example, an encoded video or audio portion of a media presentation can be an elementary stream. The elementary stream can be converted into a packetized elementary stream (PES) before being encapsulated within a video file. Within the same media presentation, a stream ID can be used to distinguish PES packets belonging to one elementary stream from others. The basic unit of data for an elementary stream is a packetized elementary stream (PES) packet. Thus, the encoded video data generally corresponds to an elementary video stream. Similarly, the audio data corresponds to one or more respective elementary streams.

[0023]

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

[0024]

[0027] Video encoder 28 can encode video data of multimedia content in various ways to generate various representations of multimedia content with various bitrates having various characteristics, such as pixel resolution, frame rate, compliance with various encoding standards, compliance with various profiles and / or levels of profiles for various encoding standards, representations having one or more displays (e.g., for 2D or 3D playback), or other such characteristics. The representations used in this disclosure may include one of audio data, video data, text data (e.g., for closed captions), or other such data. This representation may include an elementary stream such as an audio elementary stream or a video elementary stream. Each PES packet may include a stream_id that identifies the elementary stream to which the PES packet belongs. Encapsulation unit 30 is responsible for the task of assembling the elementary stream into streamable media data.

[0025]

[0028] The encapsulation unit 30 receives PES packets for the elementary streams of the media presentation from the audio encoder 26 and the video encoder 28, and forms corresponding network abstraction layer (NAL) units from the PES packets. The encoded video segment may be organized into NAL units, and the NAL units enable the addressing application of "network-friendly" video representations such as video telephony, storage, broadcast, or streaming. The NAL units can be classified into Video Coding Layer (VCL) NAL units and non-VCL NAL units. The VCL units may include a core compression engine and may include data at the block, macroblock, and / or slice level. The other NAL units may be non-VCL NAL units. In some examples, an encoded picture at one time instance is usually presented as a primary encoded picture and may be included within an access unit that may include one or more NAL units.

[0026]

[0029] The non-VCL NAL units may include, in particular, parameter set NAL units and SEI NAL units. The parameter sets may include sequence level header information (within the sequence parameter sets (SPS)) and may include picture level header information that does not change frequently (within the picture parameter sets (PPS)). When there are parameter sets (e.g., PPS and SPS), information that changes rarely does not need to be repeated for each sequence or picture, and thus the coding efficiency can be improved. Further, the use of parameter sets can enable out-of-band transmission of important header information and eliminate the need for redundant transmission for error recovery. In an example of out-of-band transmission, the NAL units of the parameter sets may be transmitted on a different channel from other NAL units such as SEI NAL units.

[0027]

[0030] Supplemental Enhancement Information (SEI) may contain information that is not necessary to decode coded picture samples from a VCL NAL unit, but may assist in 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 standards specifications and are not always essential in an implementation of a decoder compliant with the standard. SEI messages can be sequence level SEI messages or picture level SEI messages. Some sequence level information may be included within SEI messages such as scalability information SEI messages in the example of SVC and view scalability information SEI messages in MVC. These exemplary SEI messages can convey information regarding, for example, the extraction of an operating point and the characteristics of the operating point.

[0028]

[0031] Server device 60 includes a Real-time Transport Protocol (RTP) transmission unit 70 and a network interface 72. In some examples, server device 60 may include multiple network interfaces. Further, any or all of the functions of server device 60 may be implemented on other devices of a content delivery network such as a router, bridge, proxy device, switch, or other device. In some examples, an intermediate device of a content delivery network may cache data of multimedia content 64 and include components that substantially conform to the components of server device 60. Generally, network interface 72 is configured to transmit and receive data via network 74.

[0029]

[0032] The RTP transmission unit 70 is configured to deliver media data to the client device 40 via the network 74 in accordance with RTP, which is standardized in Request for Comment (RFC) 3550 by the Internet Engineering Task Force (IETF). The RTP transmission unit 70 may also implement protocols related to RTP, such as the RTP Control Protocol (RTCP), the Real-time Streaming Protocol (RTSP), the Session Initiation Protocol (SIP), and / or the Session Description Protocol (SDP). The RTP transmission unit 70 may transmit media data via the network interface 72 that may implement the Uniform Datagram Protocol (UDP) and / or the Internet protocol (IP). Therefore, in some examples, the server device 60 may use the network 74 to transmit media data via UDP through RTP and RTSP.

[0030]

[0033] The RTP transmission unit 70 may receive, for example, an RTSP description request from the client device 40. The RTSP description request may include data indicating what types of data are supported by the client device 40. The RTP transmission unit 70 may respond to the client device 40 with data indicating a media stream, 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 a uniform resource name (URN).

[0031]

[0034] Next, the RTP transmission unit 70 may receive an RTSP setup request from the client device 40. The RTSP setup request may generally indicate how the media stream should be transferred. The RTSP setup request may include a network location identifier for the requested media data (e.g., media content 64), as well as transport designators such as a local port for receiving RTP data and control data (e.g., RTCP data) on the client device 40. The RTP transmission unit 70 may reply to the RTSP setup request with an acknowledgement and data representing the port of the server device 60 to which the RTP data and control data will be sent. Next, the RTP transmission unit 70 may receive an RTSP play request to "play" the media stream, i.e., to send it to the client device 40 via the network 74. The RTP transmission unit 70 may also receive an RTSP teardown request to terminate the streaming session, and in response, the RTP transmission unit 70 may stop sending media data to the client device 40 for the corresponding session.

[0032]

[0035] Similarly, the RTP reception unit 52 may start the media stream by first sending an RTSP describe request to the server device 60. The RTSP describe request may indicate the type of data supported by the client device 40. Next, the RTP reception unit 52 may receive a reply from the server device 60 specifying an available media stream, such as media content 64, which may be sent to the client device 40, along with a corresponding network location identifier such as a Uniform Resource Locator (URL) or Uniform Resource Name (URN).

[0033]

[0036] Next, the RTP receiving unit 52 may 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 designator such as a local port for receiving RTP data and control data (e.g., RTCP data) on the client device 40. Accordingly, the RTP receiving unit 52 may receive, from the server device 60, a confirmation including the port of the server device 60 that the server device 60 will use to transmit the media data and control data.

[0034]

[0037] After establishing a media streaming session between the server device 60 and the client device 40, the RTP transmission unit 70 of the server device 60 may transmit media data (e.g., packets of 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 reception statistics by the client device 40, whereby the server device 60 may perform congestion control or otherwise diagnose and address transmission failures.

[0035]

[0038] The network interface 54 may receive the media of the selected media presentation and provide it to the RTP receiving unit 52, and the RTP receiving unit 52 may in turn provide the media data to the decapsulation unit 50. The decapsulation unit 50 decapsulates the elements of the video file into the constituent PES streams, depacketizes the PES streams to extract the encoded data, and depending on whether the encoded data is part of an audio stream or a video stream, as indicated by the PES packet header of the stream, can send the encoded data to either the audio decoder 46 or the video decoder 48. The audio decoder 46 decodes the encoded audio data and sends the decoded audio data to the audio output unit 42, while the video decoder 48 decodes the encoded video data and sends the decoded video data, which may include multiple views of the stream, to the video output unit 44.

[0036]

[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 may each be implemented as any of a variety of suitable processing circuitry, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic circuitry, software, hardware, firmware, or any combination thereof, where applicable. Each of the video encoder 28 and the video decoder 48 may be included in one or more encoders or decoders, and any of these may be integrated as part of a combined video encoder / decoder (codec). Similarly, each of the audio encoder 26 and the audio decoder 46 may be included within one or more encoders or decoders, and any of these may 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.

[0037]

[0040] The client device 40, the server device 60, and / or the content preparation device 20 may be configured to operate in accordance with the techniques of the present disclosure. By way of example, the present disclosure describes these techniques with respect to the client device 40 and the server device 60. However, it should be understood that the content preparation device 20 may be configured to implement these techniques instead of (or in addition to) the server device 60.

[0038]

[0041] The encapsulation unit 30 may form a NAL unit that includes a header identifying the program to which the NAL unit belongs, as well as the payload, such as audio data, video data, or data describing the transport or program stream corresponding to the NAL unit. For example, in H.264 / AVC, a NAL unit includes a 1-byte header and a variable-size payload. A NAL unit containing video data within its payload may include various granularity levels of video data. 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 can receive the encoded video data from the video encoder 28 in the form of PES packets of an elementary stream. The encapsulation unit 30 can associate each elementary stream with the corresponding program.

[0039]

[0042] The encapsulation unit 30 can also assemble an access unit from a plurality of NAL units. Generally, an access unit can include one or more NAL units for representing a frame of video data and, when audio data corresponding to that frame is available, such audio data. An access unit generally includes all NAL units for one output time instance, for example, all audio data and video data for one 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) can be rendered simultaneously. In one example, an access unit may include a coded picture within one time instance, which may be presented as a coded primary picture.

[0040]

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

[0041]

[0044] After the encapsulation unit 30 assembles 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, instead of directly sending the video file to the client device 40, the encapsulation unit 30 can store the video file locally or send the video file to a remote server via the output interface 32. The output interface 32 may include, for example, a transmitter, a transceiver, a device for writing data to a computer-readable medium such as an optical drive, a magnetic media drive (e.g., a floppy drive), a universal serial bus (USB) port, a network interface, or other output interfaces. The output interface 32 outputs the video file to a computer-readable medium such as, for example, a transmission signal, a magnetic media, an optical media, a memory, a flash drive, or other computer-readable media.

[0042]

[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 decapsulates the elements of the video file into the constituent PES streams, depacketizes those PES streams to retrieve the encoded data, and transmits the encoded data to either the audio decoder 46 or the video decoder 48 depending on whether the encoded data, indicated for example by the PES packet header of the stream, is part of an audio stream or part of a video stream. The audio decoder 46 decodes the encoded audio data and transmits the decoded audio data to the audio output section 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 section 44.

[0043]

[0046] The above-described techniques are described with respect to RTP for illustrative purposes. However, the techniques of the present disclosure may use other protocols for transferring media data, such as HTTP streaming-based protocols, for example, Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS). In HTTP streaming such as Dynamic Adaptive Streaming over HTTP (DASH), operations frequently used include HEAD, GET, and partial GET. The HEAD operation retrieves the header of a 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 consecutive number of bytes of the file, where the number of bytes corresponds to the received byte range. Thus, since the partial GET operation can obtain one or more individual movie fragments, movie fragments may be provided for HTTP streaming. In a movie fragment, there may be several track fragments of different tracks. In HTTP streaming, a media presentation may be a structured collection of data accessible to a client. The client can request and download media data information to present a streaming service to the user.

[0044]

[0047] In an example of streaming 3GPP data using HTTP streaming, there may be multiple representations for the video data and / or audio data of the multimedia content. As described below, different representations may correspond to different coding characteristics (e.g., different profiles or levels of a video coding standard), different coding standards or extensions of a coding standard (such as multi-view and / or scalable extensions), or different bitrates. The manifest of such representations may be defined in a Media Presentation Description (MPD) data structure. A media presentation may correspond to a structured collection of data accessible to an HTTP streaming client device. The HTTP streaming client device can request and download media data information to present a streaming service to the user of the client device. The media presentation may be described in an MPD data structure that may include an update of the MPD.

[0045]

[0048] A media presentation may include a sequence of one or more periods. Each period may extend until the start of the next period, or in the case of the last period, until the end of the media presentation. Each period may include one or more representations for the same media content. A representation may be one of several alternative encoded versions of audio, video, timed text, or other such data. Representations may differ by the type of encoding, e.g., the bitrate, resolution, and / or codec of video data, and the bitrate, language, and / or codec of audio data. The term representation may be used to refer to a section of encoded audio data or encoded video data corresponding to a particular period of multimedia content and encoded in a particular way.

[0046]

[0049] The representation 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 within the same adaptation set are generally considered to be alternatives to each other in that a client device can switch dynamically and seamlessly 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 to be decoded to present media data, such as video data or audio data, of the multimedia content for the corresponding period. In some examples, the media content within one period may be represented by one representation from group 0 if group 0 exists, or by any combination of at most one representation from each non-zero group. The timing data for each representation of a period may be represented relative to the start time of the period.

[0047]

[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. The initialization segment, when present, may include initialization information for accessing the representation. Generally, the initialization segment does not contain media data. A segment may be uniquely referenced by an identifier, such as a Uniform Resource Locator (URL), Uniform Resource Name (URN), or 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, corresponding to data for a segment within a file accessible by a URL, URN, or URI.

[0048]

[0051] Different representations may be selected to perform retrieval substantially simultaneously for different types of media data. For example, a client device may select an audio representation, a video representation, and a time-limited text representation for retrieving segments. In some examples, the client device may select a particular set of adaptations to perform bandwidth adaptation. That is, the client device may select a set of adaptations including a video representation, a set of adaptations including an audio representation, and / or a set of adaptations including time-limited text. Alternatively, the client device may select a set of adaptations for one type of media (e.g., video) and directly select representations for other types of media (e.g., audio and / or time-limited text).

[0049]

[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 language preferences selected by the user of the client device 40, one or more camera views corresponding to the depth preferences set by the user of the client device 40, and / or the rating preferences selected by the user of the client device 40. The client device 40 may comprise, for example, a web browser or media client configured to submit HTTP GET 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 with respect to the client device 40 may be implemented in hardware, or in a combination of hardware, software, and / or firmware, in which case the essential hardware may be provided to execute instructions for the software or firmware.

[0050]

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

[0051]

[0054] Generally, as the bitrate of a representation increases, the quality of video playback increases, while as the bitrate of a representation decreases, the quality of video playback may be sufficient when the available network bandwidth is reduced. Thus, when the available network bandwidth is relatively high, the client device 40 can retrieve data from a representation with a relatively high bitrate, and when the available network bandwidth is low, the client device 40 can retrieve data from a representation with a relatively low bitrate. In this way, the client device 40 can stream multimedia data via the network 74 while also adapting to the changing availability of the network bandwidth of the network 74.

[0052]

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

[0053]

[0056] FIG. 2 is a block diagram showing an architecture 100 for a system that may be configured to perform immersive real-time communication (iRTCW) for web real-time communication (WebRTC) according to the techniques of the present disclosure. In particular, the architecture 100 may be used for 5G media streaming (5GMS) using WebRTC. That is, the architecture 100 may be used to perform WebRTC real-time communication through a 5G network connection.

[0054]

[0057] Architecture 100 can be used to provide WebRTC in various scenarios. As an example, 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 architecture 100 to provide a reliable WebRTC function and / or a facility WebRTC service. As yet another example, architecture 100 can provide interoperable WebRTC services. Architecture 100 can also be used for various other scenarios. Architecture 100 provides flexibility through a set of functions and interfaces that can be combined in different ways based on the requirements for a particular scenario.

[0055]

[0058] In the example of FIG. 2, architecture 100 includes a 5G RTC application provider 102, a 5G RTC application function 104, and a user equipment (UE) 150. Generally, the 5G RTC application provider 102 interacts with the functions of the 5G RTC application function 104 and supplies 5G RTC-enabled applications such as a web application 152 to the user equipment 150.

[0056]

[0059] User equipment 150 may also be referred to as a "UE" or "client device". UE 150 may correspond to client device 40 in FIG. 1. User equipment 150 can be, for example, a laptop or desktop computer, digital camera, digital recording device, digital media player, video game device, video game console, cellular or satellite radiotelephone, video teleconference device, or the like. In this example, user equipment 150 includes a web application 152, a native WebRTC application 154, and a media session handler (MSH) 158. Web application 152, native WebRTC application 154, and MSH 156 may correspond to RTP receiving unit 52 in FIG. 1. Interface 156 couples native WebRTC application 154 and MSH 158. Interface 156 may be referred to as the "RTC-6" interface. UE 150 and 5G RTC application provider 102 are coupled by an interface 174, which may be referred to as the "RTC-8" interface.

[0057]

[0060] MSH158 is a function within the UE150 that provides access to WebRTC applications, such as web application 152, and 5G RTC support functions, such as 5G RTC application function 104. These functions can be provided transparently in response to requests through interface 156 (RTC-6 interface) or without the direct involvement of web application 154. MSH158 can indirectly assist in Interactive Connectivity Establishment (ICE) negotiation, for example, by providing a list of Session Traversal Utilities for Network Address Translation (STUN) and / or Relay-using NAT Traversal (TURN) server candidates that provide 5G RTC functionality. MSH158 can also collect Quality of Experience (QoE) metric reports and submit consumption reports. MSH158 can also provide media configuration recommendations to web application 152 through interface 156 (RTC-6).

[0058]

[0061] According to "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G Media Streaming (5GMS); Protocol" (Release 17) TS 26.512, (March 2022), the media session handler of the UE maintains the following internal characteristics:

[0059]

Table 1

[0060]

[0062] MSH158 can be initiated when the native WebRTC application 154 makes a call to the Media Presentation Description (MPD) URL. During the WebRTC session, MSH158 can send consumption reports, for example, to the 5G RTC application provider 102. The consumption reports can generally indicate the content consumed by the UE150. The network assistance configuration can represent the bitrate recommendations and delivery boosts from the 5G RTC AF104. The policy template configuration can represent one or more policies selected from a set of policy templates configured during the provisioning session. The metric reporting configuration can represent the metric reports to be delivered to the 5G RTC AF104, such as the content of the metric reports, the delivery frequency of the metric reports, or the like.

[0061]

[0063] The interface 170 (which may be referred to as the "RTC-1" interface) enables the 5G RTC application provider 102 to provision support for the RTC sessions provided as the 5G RTC application function 104. The provisioning can include functionality such as quality of service (QoS) for the WebRTC session, billing provisioning for the WebRTC session, collection of consumption and QoE metric data related to the WebRTC session, providing ICE functionality such as STUN and TURN servers, and / or providing a WebRTC signaling server with interoperability with potentially other signaling servers.

[0062]

[0064] 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 is also interoperable with a policy and charging function (PCF) 160, a network exposure function (NEF) 162, and a session management function (SMF) 164.

[0063]

[0065] An interface 170, which may be referred to as a "provisioning interface", is not necessarily relevant to all cooperation scenarios, and some of the 5G support functionality may be provided without application provider provisioning.

[0064]

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

[0065]

[0067] MSH158 may provide support functionality such as informing, starting, or requesting QoS allocation for a changed WebRTC session about the WebRTC session and its state to the 5G RTC application function 104 or the web application 152, receiving a notification regarding a change in QoS allocation for an ongoing WebRTC session, or receiving, updating, or exchanging information about the WebRTC session, for example, to identify the WebRTC session and associate it with a QoS template, with the 5G RTC STUN / TURN / signaling server.

[0066]

[0068] In some examples, the 5G functionality that provides the application function to a WebRTC application (including the 5G RTC data channel AF116, the 5G RTC signaling server AF118, the 5G RTC interop AF120, the 5G RTC STUN AF122, and the 5G RTC TURN AF124) may instead be provided by an application server (5G RTC AS) instead of the AF. The 5G RTC AS could then use a dedicated RTC-3 interface to request configuration and network support for an ongoing WebRTC session from the 5G RTC AF.

[0067]

[0069] The functionality attributable to the 5G RTC application provider 102, the 5G RTC application function 104, and the UE 150 may be implemented in the form of hardware, software, firmware, or any combination thereof. When implemented in the form of software or firmware, memory may be provided to store instructions executable by one or more processors implemented within the circuitry. The processor may include one or more of a microprocessor, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic circuitry, or any combination thereof.

[0068]

[0070] Thus, UE150 is a device for exchanging media data, including a memory configured to store media data and one or more processors implemented within a circuit mechanism, and the one or more processors interact with one or more application functions provided by an application provider device, where 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 for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function. The UE150 executes a media session handler (MSH) to interact with the one or more application functions, receives a web application from the application provider device, and is configured to exchange media data among the one or more application functions provided by the application provider device, the MSH, and the web application, representing an example of the device.

[0069]

[0071] FIG. 3 is a call flow diagram showing an exemplary method for initiating a WebRTC media session according to the techniques of the present disclosure. In some examples, a 5G system for a WebRTC session may provide integrated support by providing 5G RTC STUN functionality.

[0070]

[0072] The 5G RTC STUN AF is a STUN server (compliant with RFC8489). Additionally, the 5G RTC STUN AF server provides 5G functionality for supporting WebRTC sessions. The STUN server receives binding requests as part of the ICE negotiation. These requests enable the STUN server to discover the public IP address and port number of the connection, so-called, the reflexive transport address. The requests and responses may include STUN attributes that can be labeled as comprehension-required or comprehension-optional. A STUN server not configured to interpret comprehension-required attributes may reply with an error message. IANA maintains a registry of STUN attributes.

[0071]

[0073] This disclosure describes additional STUN attributes that can be used to trigger 5G support for WebRTC applications. These attributes may enable the 5G RTC STUN server to request, for example, QoS allocation and charging for media connections. The following attributes are examples of additional STUN attributes that may be comprehension-optional attributes: 3GPP-PRIVATE-ADDRESS: Corresponds to the protocol family indicator, IP address, and port number of the private transport address as seen by the UE; 3GPP-QOS: Indicates the QoS attributes associated with the connection associated with this request. This may include average bitrate, maximum bitrate, maximum latency, and maximum packet loss rate (PLR) indicators; and 3GPP-CODEC: Represents the codec mime type and codec parameters that describe the codec to be used for this connection, and multiple values may be provided.

[0072]

[0074] A 5G RTC STUN server may support these attributes. The 5G RTC STUN server may use the information in a successful binding to request QoS allocation and charging policies. 5G RTC STUN may also respond with recommendations regarding target QoS parameters and / or a recommended codec using STUN attributes.

[0073]

[0075] Regarding the example of FIG. 3, an application service provider (ASP) (e.g., the 5G RTC application provider 102 of FIG. 2) that provides better 5G support for the WebRTC-based application creates (200) a provisioning session with the 5G RTC provisioning AF114. This step is optional, and the mobile network operator (MNO) may decide to provide support for the WebRTC session without an associated provisioning session.

[0074]

[0076] Next, the 5G RTC provisioning AF114 may share the QoS and media configuration templates with all relevant 5G RTC AFs 104 (202). This may be done, for example, by storing this information within a unified data management function (UDF).

[0075]

[0077] Next, the 5G RTC configuration AF112 may send (204) the WebRTC configuration, including the STUN and TURN server lists, to the MSH158 as part of the service access information.

[0076]

[0078] The web application 152 may fetch (206) a list of pre-configured STUN and TURN servers from the local configuration, e.g., via the MSH158. The configuration may indicate for each server whether the server is 5G RTC compliant.

[0077]

[0079] Next, the web application 152 may submit a binding request with additional attributes to the 5G RTC STUN AF122 server to trigger ICE negotiation (208).

[0078]

[0080] The 5G RTC STUN AF122 extracts the relevant QoS template and media configuration (210).

[0079]

[0081] The 5G RTC STUN AF122 creates a binding response and sends it back to the web application 152 with additional information along with the address binding (212).

[0080]

[0082] The web application 152 updates the offer / answer session description protocol (SDP) based on the received STUN information (214). Next, the WebRTC media session may be started (216). That is, the web application 152 may send and / or receive media data via the WebRTC media session.

[0081]

[0083] To configure the WebRTC session, the MSH158 may receive a list of 5G RTC STUN and TURN servers provided by the MNO for the 5G system integration of the WebRTC session. The MSH158 may also receive recommendations regarding the QoS template for the WebRTC session. The MSH makes this information available to the web application 152 through interface 156, i.e., the RTC-6 interface.

[0082]

[0084] The information may be formatted as follows:

[0083]

Table 2

[0084]

[0085] For web applications such as web application 152, configuration information may be accessible through standardized W3C APIs such as the Indexed Database API or the File API.

[0085]

[0086] The 5G RTC STUN server may use the N5 or N33 interface to request QoS allocation for related STUN bindings. Once it determines the 3-tuple (public IP address, port number, and protocol) for the connection, the 5G RTC STUN server may call the Nnef_AFsessionWithQoS or Npcf_PolicyAuthorization method to request QoS for the identified QoS flow.

[0086]

[0087] Figure 4 is a flowchart showing an exemplary method for establishing a WebRTC session within a wireless access network according to the techniques of the present disclosure. The method of Figure 4 is described with respect to UE150 of Figure 2. However, other devices such as client device 40 of Figure 1 may also execute this method or a similar method.

[0087]

[0088] As described above, UE150 may execute MSH158 to interact with one or more application functions such as RTC AF140 of Figure 2. UE150 may also execute native WebRTC application 154 to perform WebRTC operations, such as sending and receiving media data via a WebRTC session. Specifically, UE150 may execute MSH158 to receive interactive connectivity establishment (ICE) configuration information for the WebRTC session (250). The ICE configuration information may include a list of ICE candidates, and for each ICE candidate, a type for the ICE candidate (e.g., STUN or TURN), a URL to access the ICE candidate, and an indication of whether the ICE candidate is 5G-capable.

[0088]

[0089] Using the received ICE configuration information, MSH158 may select one of the 5G RTC-compliant ICE candidates (252). Next, MSH158 may send a binding request to the selected ICE candidate (254). The binding request may include additional attributes for triggering ICE negotiation. The attributes may include, for example, 3GPP private address data including a protocol family indicator, an IP address, and a port number corresponding to the private transport address as seen by UE150. The attributes may also include 3GPP service quality (QoS) data indicating QoS attributes associated with the connection associated with the request. The QoS attributes may include an average bit rate, a maximum bit rate, a maximum latency, and a packet loss rate (PLR) indication. The attributes may further include 3GPP codec data indicating one or more codec mime types and codec parameters (s) describing the codec (s) to be used for this connection.

[0089]

[0090] Next, MSH158 may receive a binding response from the ICE candidate, and the binding response may include 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, a type (e.g., whether the media is audio, video, text, or the like), a codec configuration for the media, a recommended average bit rate for the media, and a recommended peak or maximum bit rate for the media. Next, MSH158 may update the session description offer or answer using the received information (258) and may establish a WebRTC session (260). Next, web application 152 may participate in the virtual scene and transmit and receive application layer data via native WebRTC application 154, which may encapsulate and decapsulate WebRTC data into various formats for web application 152. In this way, web application 152 may exchange media data via the WebRTC session (262).

[0090]

[0091] Accordingly, the method of FIG. 4 is a method for interacting with one or more application functions provided by an application provider device, where 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 for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function, and includes executing a media session handler (MSH), receiving a web application from the application provider device, and exchanging data among the one or more application functions, the MSH, and the web application provided by the application provider device, which represents an example of the method.

[0091]

[0092] Examples of some techniques of this disclosure are summarized in the following clauses.

[0092]

[0093] Clause 1: A device for retrieving media data, the device comprising a memory configured to store media data and one or more processors implemented within a circuit mechanism, the one or more processors interacting 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function, the device executing a media session handler (MSH) to interact with the one or more application functions, receiving a web application from the application provider device, and being configured to exchange data among the one or more application functions provided by the application provider device, the MSH, and the web application.

[0093]

[0094] Clause 2: The device according to 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 media data via the WebRTC session.

[0094]

[0095] Clause 3: The device according to Clause 1 or 2, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0095]

[0096] Clause 4: One or more processors 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 answer according to the received binding information, and are further configured to start a WebRTC media session according to the updated SDP offer or answer. The device according to any one of Clauses 1 to 3.

[0096]

[0097] Clause 5: An application provider device comprising a memory configured to store media data and one or more processors implemented within a circuitry, the one or more processors providing 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 Relay-using NAT Traversal (TURN) application function, providing a web application to a User Equipment (UE) device, and configured to exchange data between the one or more application functions and the UE device.

[0097]

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

[0098]

[0099] Clause 7: The device according to Clause 5 or 6, wherein one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0099]

[0100] Clause 8: The application provider device according to any one of Clauses 5 to 7, wherein one or more processors share one or more Quality of Service (QoS) templates and Session Traversal Utilities for Network Address Translation (STUN) server configuration data, send WebRTC configuration data compliant with the QoS templates and STUN server configuration data to a UE device, receive a binding request having configuration parameters from the UE device, verify the validity of the binding request using the QoS templates and STUN server configuration data, and are further configured to send binding information including QoS and codec recommendations to a client device to start a WebRTC session.

[0100]

[0101] Clause 9: A method for retrieving media data, the method comprising: interacting with one or more application functions provided by an application provider device, 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 utility for network address translation (STUN) application function, or a relay used NAT traversal (TURN) application function, by executing a media session handler (MSH); receiving a web application from the application provider device; and exchanging data among the one or more application functions, the MSH, and the web application provided by the application provider device.

[0101]

[0102] Clause 10: The method according to clause 9, further comprising participating in a web real-time communication (WebRTC) session using one or more application functions to send or receive media data via the WebRTC session.

[0102]

[0103] Clause 11: The method according to clause 9 or 10, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0103]

[0104] Clause 12: Receiving WebRTC configuration data from a constituent application function, determining Interactive Connectivity Establishment (ICE) and media configuration parameters from the WebRTC configuration data, submitting a binding request to a Network Address Translation Session Traversal Utility (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 answer according to the received binding information, and starting a WebRTC media session according to the updated SDP offer or answer, the method according to any one of Clauses 9 to 11 further comprising.

[0104]

[0105] Clause 13: A method, comprising providing one or more application functions, 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 Network Address Translation Session Traversal Utility (STUN) application function, or a Relay-Used NAT Traversal (TURN) application function, providing a web application to a user equipment (UE) device, and exchanging data between the one or more application functions and the UE device.

[0105]

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

[0106]

[0107] Clause 15: The method according to Clause 13 or 14, wherein one or more application functions further include one or more of a policy charging function, a network exposer function, or a session management function.

[0107]

[0108] Clause 16: The method according to any one of Clauses 13 to 15, further including sharing one or more quality of service (QoS) templates and session traversal utility (STUN) server configuration data for network address translation, transmitting WebRTC configuration data according to the QoS templates and the STUN server configuration data to a UE device, receiving a binding request having configuration parameters from the UE device, verifying the validity of the binding request using the QoS templates and the STUN server configuration data, and transmitting binding information including QoS and codec recommendations to a client device to start a WebRTC session.

[0108]

[0109] Clause 17: A computer-readable storage medium that, when executed, stores instructions for causing a processor to execute the method according to any one of Clauses 9 to 16.

[0109]

[0110] 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 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 Relay-Using NAT Traversal (TURN) application function; means for receiving a web application from the application provider device; and means for exchanging data among the one or more application functions provided by the application provider device, the MSH, and the web application.

[0110]

[0111] Clause 19: A device comprising means for providing 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 Relay-Using NAT Traversal (TURN) application function; means for providing a web application to a User Equipment (UE) device; and means for exchanging data between the one or more application functions and the UE device.

[0111]

[0112] Clause 20: A device for exchanging media data, the device comprising a memory configured to store media data, and one or more processors implemented within a circuitry, the one or more processors interacting 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function, the one or more processors executing a media session handler (MSH) to interact with the one or more application functions, receiving a web application from the application provider device, and being configured to exchange media data among the one or more application functions provided by the application provider device, the MSH, and the web application.

[0112]

[0113] Clause 21: The device according to Clause 20, wherein the one or more processors are configured to transmit or receive media data via a web real-time communication (WebRTC) session with the one or more application functions to exchange media data among the one or more application functions, the MSH, and the web application.

[0113]

[0114] Clause 22: The device according to Clause 20 or 21, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0114]

[0115] Clause 23: One or more processors receive Web Real-Time Communication (WebRTC) configuration data from the configured application functions among 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 answer according to the received binding information, and are further configured to start a WebRTC media session according to the updated SDP offer or answer, the device according to any one of Clauses 20 to 22.

[0115]

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

[0116]

[0117] Clause 25: The MSH is configured to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations including, for each media configuration recommendation, data representing the media type, codec, average bit rate, and maximum bit rate, the device according to any one of Clauses 20 to 24.

[0117]

[0118] 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, 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function; receiving a web application from the application provider device; and exchanging data among the one or more application functions, the MSH, and the web application provided by the application provider device.

[0118]

[0119] Clause 27: The method according to Clause 26, wherein exchanging media data among the one or more application functions, the MSH, and the web application includes transmitting or receiving media data via a web real-time communication (WebRTC) session with the one or more application functions.

[0119]

[0120] Clause 28: The method according to Clause 26 or 27, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0120]

[0121] Clause 29: Receiving Web Real-Time Communication (WebRTC) configuration data from a constituent application function among 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 answer according to the received binding information; and starting a WebRTC media session according to the updated SDP offer or answer, the method according to any one of Clauses 26 to 28 further comprising this.

[0121]

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

[0122]

[0123] Clause 31: Further comprising receiving, by the MSH, a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations including, for each media configuration recommendation, data representing the media type, codec, average bit rate, and maximum bit rate, the method according to any one of Clauses 26 to 30.

[0123]

[0124] Clause 32: A computer-readable storage medium which, when executed, causes a processor to interact with one or more application functions provided by an application provider device, where 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 for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function, to execute a media session handler (MSH) to receive a web application from the application provider device, and to exchange media data among the one or more application functions, the MSH, and the web application provided by the application provider device.

[0124]

[0125] Clause 33: The computer-readable storage medium according to Clause 32, wherein instructions to cause the processor to exchange media data among one or more application functions, the MSH, and the web application include instructions to cause the processor to transmit or receive media data via a web real-time communication (WebRTC) session with one or more application functions.

[0125]

[0126] Clause 34: The computer-readable storage medium according to Clause 32 or 33, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0126]

[0127] Clause 35: The computer-readable storage medium according to any one of Clauses 32 to 34, further including an instruction for causing a processor to receive Web Real-Time Communication (WebRTC) configuration data from a configured application function among 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 answer according to the received binding information, and start a WebRTC media session according to the updated SDP offer or answer.

[0127]

[0128] Clause 36: The computer-readable storage medium according to 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 ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant.

[0128]

[0129] Clause 37: The computer-readable storage medium according to any one of Clauses 32 to 36, further including an instruction for causing a processor to execute an MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, wherein the list of media configuration recommendations includes data representing a media type, a codec, an average bitrate, and a maximum bitrate for each media configuration recommendation.

[0129]

[0130] Clause 38: 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, 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function; means for receiving a web application from the application provider device; and means for exchanging data between the one or more application functions, the MSH, and the web application provided by the application provider device.

[0130]

[0131] Clause 39: The device according to Clause 38, wherein the means for exchanging media data between the one or more application functions, the MSH, and the web application includes means for transmitting or receiving media data via a web real-time communication (WebRTC) session with the one or more application functions.

[0131]

[0132] Clause 40: The device according to Clause 38 or 39, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0132]

[0133] Clause 41: Means for receiving Web Real-Time Communication (WebRTC) configuration data from the constituent application functions of 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 according to the received binding information, and means for starting a WebRTC media session according to the updated SDP offer or answer, the device according to any one of Clauses 38 to 40, further comprising.

[0133]

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

[0134]

[0135] Clause 43: Further comprising means for executing an MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations including, for each media configuration recommendation, data representing media type, codec, average bit rate, and maximum bit rate, the device according to any one of Clauses 38 to 42.

[0135]

[0136] Clause 44: A device for exchanging media data, the device comprising a memory configured to store media data and one or more processors implemented within a circuitry, the one or more processors interacting 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 utility for network address translation (STUN) application function, or a relay used network address translation (TURN) application function, the device executing a media session handler (MSH) to interact with the one or more application functions, receiving a web application from the application provider device, and configured to exchange media data among the one or more application functions provided by the application provider device, the MSH, and the web application.

[0136]

[0137] Clause 45: The device according to Clause 44, wherein the one or more processors are configured to transmit or receive media data via a web real-time communication (WebRTC) session with the one or more application functions for exchanging media data among the one or more application functions, the MSH, and the web application.

[0137]

[0138] Clause 46: The device according to Clause 44, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0138]

[0139] Clause 47: One or more processors receive Web Real-Time Communication (WebRTC) configuration data from the configured application functions among 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 answer according to the received binding information, and are further configured to start a WebRTC media session according to the updated SDP offer or answer, the device described in Clause 44.

[0139]

[0140] Clause 48: The ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and for each ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant, the device described in Clause 47.

[0140]

[0141] Clause 49: The MSH is configured to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, and the list of media configuration recommendations includes, for each media configuration recommendation, data representing the media type, codec, average bit rate, and maximum bit rate, the device described in Clause 44.

[0141]

[0142] 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 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function; receiving a web application from the application provider device; and exchanging data among the one or more application functions, the MSH, and the web application provided by the application provider device.

[0142]

[0143] Clause 51: The method according to clause 50, wherein exchanging media data among the one or more application functions, the MSH, and the web application includes transmitting or receiving media data via a web real-time communication (WebRTC) session with the one or more application functions.

[0143]

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

[0144]

[0145] Clause 53: Receiving Web Real-Time Communication (WebRTC) configuration data from a constituent application function among 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 answer according to the received binding information; and starting a WebRTC media session according to the updated SDP offer or answer, the method according to Clause 50 further comprising the above steps.

[0145]

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

[0146]

[0147] Clause 55: The method according to Clause 50 further comprising receiving, by the MSH, a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, the list of media configuration recommendations including, for each media configuration recommendation, data representing media type, codec, average bit rate, and maximum bit rate.

[0147]

[0148] Clause 56: A computer-readable storage medium which, when executed, causes a processor to interact with one or more application functions provided by an application provider device, where 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 Relay-using NAT Traversal (TURN) application function, by causing the Media Session Handler (MSH) to execute, receive a web application from the application provider device, and exchange media data among the one or more application functions provided by the application provider device, the MSH, and the web application.

[0148]

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

[0149]

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

[0150]

[0151] Clause 59: The computer-readable storage medium according to clause 56 further includes an instruction for causing a processor to receive Web Real-Time Communication (WebRTC) configuration data from a configured application function among 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 answer according to the received binding information, and start a WebRTC media session according to the updated SDP offer or answer.

[0151]

[0152] Clause 60: The computer-readable storage medium according to 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 ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant.

[0152]

[0153] Clause 61: The device according to clause 56 further includes an instruction for causing a processor to execute an MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, wherein the list of media configuration recommendations includes, for each media configuration recommendation, data representing a media type, a codec, an average bit rate, and a maximum bit rate.

[0153]

[0154] Clause 62: A device for exchanging media data, the device being 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 Relay-using NAT Traversal (TURN) application function, means for executing a Media Session Handler (MSH) to interact with the one or more application functions, means for receiving a web 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 web application.

[0154]

[0155] Clause 63: The device according to Clause 62, wherein the means for exchanging media data between the one or more application functions, the MSH, and the web application includes means for transmitting or receiving media data via a Web Real-Time Communication (WebRTC) session with the one or more application functions.

[0155]

[0156] Clause 64: The device according to Clause 62, wherein the one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0156]

[0157] Clause 65: Means for receiving Web Real-Time Communication (WebRTC) configuration data from the constituent application functions of 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 according to the received binding information; and means for starting a WebRTC media session according to the updated SDP offer or answer. The device according to Clause 62 further comprises these means.

[0157]

[0158] Clause 66: The ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and for each ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant. The device according to Clause 65 includes these.

[0158]

[0159] Clause 67: The device according to Clause 62 further comprises means for executing an MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, where the list of media configuration recommendations includes, for each media configuration recommendation, data representing the media type, codec, average bit rate, and maximum bit rate.

[0159]

[0160] Clause 68: A device for exchanging media data, the device comprising a memory configured to store media data and one or more processors implemented within a circuitry, the one or more processors executing a Media Session Handler (MSH) to interact with one or more application functions provided by an application provider device, extracting configuration information related to Web Real-Time Communication (WebRTC) from the MSH, and using the configuration information to establish a WebRTC session and execute an application to exchange media data via the WebRTC session.

[0160]

[0161] Clause 69: The device 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 Relay NAT (TURN) application function.

[0161]

[0162] Clause 70: The device according to Clause 68, wherein the one or more application functions include one or more of a policy charging function or a session management function.

[0162]

[0163] Clause 71: One or more processors receive Web Real-Time Communication (WebRTC) configuration data from a configured application function among 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 answer according to the received binding information, and are further configured to start a WebRTC media session according to the updated SDP offer or answer, the device according to clause 68.

[0163]

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

[0164]

[0165] Clause 73: The binding request is configured to instruct one of a STUN server application function or a TURN server application function to request a QoS assignment from a policy application function, the device according to clause 71.

[0165]

[0166] Clause 74: The MSH is configured to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, and the list of media configuration recommendations includes, for each media configuration recommendation, data representing the media type, codec, average bitrate, and maximum bitrate, the device according to clause 68.

[0166]

[0167] 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 an application to extract configuration information related to Web Real-Time Communication (WebRTC) from the MSH; and using the configuration information to establish a WebRTC session and executing an application to exchange media data via the WebRTC session.

[0167]

[0168] Clause 76: The 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 Relay-using NAT Traversal (TURN) application function.

[0168]

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

[0169]

[0170] Clause 78: Receiving Web Real-Time Communication (WebRTC) configuration data from constituent application functions among 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 answer according to the received binding information; and starting a WebRTC media session according to the updated SDP offer or answer. The method according to clause 75 further includes these steps.

[0170]

[0171] Clause 79: The ICE and media configuration parameters include a list of ICE server application functions that can be used for ICE negotiation, and for each ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant. The method according to clause 78 includes these contents.

[0171]

[0172] Clause 80: The binding request is configured to instruct one of a STUN server application function or a TURN server application function to request a QoS assignment from a policy application function. The method according to clause 78 is configured like this.

[0172]

[0173] Clause 81: The method according to clause 75 further includes receiving, by the MSH, a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, and the list of media configuration recommendations includes, for each media configuration recommendation, data representing the media type, codec, average bit rate, and maximum bit rate.

[0173]

[0174] Clause 82: A computer-readable storage medium that, when executed, causes a processor to execute a media session handler (MSH) to interact with one or more application functions provided by an application provider device, and stores instructions for causing an application to be executed.

[0174]

[0175] Clause 83: The computer-readable storage medium according to Clause 82, wherein 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 for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function.

[0175]

[0176] Clause 84: The computer-readable storage medium according to Clause 82, wherein one or more application functions further include one or more of a policy charging function, a network exposure function, or a session management function.

[0176]

[0177] Clause 85: The computer-readable storage medium according to Clause 82, further including an instruction for causing a processor to receive Web Real-Time Communication (WebRTC) configuration data from a configured application function among 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 answer according to the received binding information, and start a WebRTC media session according to the updated SDP offer or answer.

[0177]

[0178] Clause 86: The computer-readable storage medium according to 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 ICE server application function, data representing the type for the ICE server application function, the URL of the ICE server application function, and whether the ICE server application function is 5G-RTC compliant.

[0178]

[0179] Clause 87: The computer-readable storage medium according to Clause 82, further including an instruction for causing a processor to execute an MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, wherein the list of media configuration recommendations includes data representing, for each media configuration recommendation, a media type, a codec, an average bit rate, and a maximum bit rate.

[0179]

[0180] Clause 88: 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 extract configuration information related to Web Real-Time Communication (WebRTC) from the MSH, and means for exchanging data between one or more application functions provided by the application provider device, the MSH, and a web application.

[0180]

[0181] Clause 89: The device 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 utility for network address translation (STUN) application function, or a relay-using NAT traversal (TURN) application function.

[0181]

[0182] Clause 90: The device according to 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.

[0182]

[0183] Clause 91: Means for receiving Web Real-Time Communication (WebRTC) configuration data from the constituent application functions of 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 the STUN server application function or the 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 according to the received binding information, and means for starting a WebRTC media session according to the updated SDP offer or answer, the device according to Clause 88, further comprising.

[0183]

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

[0184]

[0185] Clause 93: The binding request is configured to instruct one of the STUN server application function or the TURN server application function to request a QoS assignment from the policy application function, the device according to Clause 91.

[0185]

[0186] Clause 94: The device according to clause 88, further comprising means for the MSH to execute to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, wherein the list of media configuration recommendations includes, for each media configuration recommendation, data representing media type, codec, average bit rate, and maximum bit rate.

[0186]

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

[0187]

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

[0188]

[0189] The commands can 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 logic circuit mechanisms or discrete logic circuit mechanisms. Thus, the term "processor" as used herein may refer to either the above structures, or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functions described herein may be provided within dedicated hardware modules and / or software modules configured for encoding and decoding, or may be incorporated within a composite codec. Also, the techniques may be implemented entirely in one or more circuits or logic elements.

[0189]

[0190] The techniques of the present disclosure may be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chip sets). To emphasize the functional aspects of devices configured to implement the disclosed techniques, various components, modules, or units have been described in this disclosure, but they do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit, or may be provided by a set of interoperable hardware units that include one or more of the processors described above in conjunction with suitable software and / or firmware.

[0190]

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

Claims

1. A method for exchanging media data, wherein the method is Executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, The process involves running an application to retrieve configuration information related to Web Real-Time Communication (WebRTC) from the aforementioned MSH, Using the aforementioned configuration information, the system establishes a WebRTC session and executes the application to exchange media data via the WebRTC session, wherein the application is a native WebRTC application configured to send and receive WebRTC session data via the MSH. Methods that include...

2. The method according to claim 1, wherein the one or more application functions include one or more of the following: 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 relay-based NAT traversal (TURN) application function.

3. The method according to claim 1, wherein the one or more application functions include one or more of the policy billing functions or session management functions.

4. Receiving Web Real-Time Communication (WebRTC) configuration data from the configuration application function of one or more application functions, The interactive connectivity establishment (ICE) and media configuration parameters are determined from the aforementioned WebRTC configuration data. A binding request is submitted to either the STUN server application function or the TURN server application function using the ICE and media configuration parameters. In response to the aforementioned binding request, the system receives binding information including quality of service (QoS) and codec data. Updating the Session Description Protocol (SDP) offer or answer according to the received binding information, To initiate a WebRTC media session in accordance with the aforementioned updated SDP offer or answer, The method according to claim 1, further comprising:

5. The method according to 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 ICE server application function, 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 compatible.

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

7. The method according to claim 1, further comprising receiving a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer via the MSH, wherein the list of media configuration recommendations includes data representing, for each media configuration recommendation, a media type, a codec, an average bitrate, and a maximum bitrate.

8. A device for exchanging media data, wherein the device is Means for executing a media session handler (MSH) to interact with one or more application functions provided by an application provider device, A means for executing an application to extract configuration information related to Web Real-Time Communication (WebRTC) from the aforementioned MSH, A means for establishing a WebRTC session using the aforementioned configuration information and executing the application to exchange media data via the WebRTC session, wherein the application is a native WebRTC application configured to send and receive WebRTC session data via the MSH. A device equipped with the following features.

9. The device according to claim 8, wherein the one or more application functions include one or more of the following: support application functions, configuration application functions, provisioning application functions, channel application functions, signaling server application functions, interoperability application functions, network address translation session traversal utility (STUN) application functions, or relay-based NAT traversal (TURN) application functions.

10. The device according to claim 8, wherein the one or more application functions include one or more of the following: a policy billing function, a network exposure function, or a session management function.

11. Means for receiving Web Real-Time Communication (WebRTC) configuration data from the configuration application functions of one or more application functions, Means for determining interactive connectivity establishment (ICE) and media configuration parameters from the aforementioned WebRTC configuration data, Means for submitting a binding request to either the STUN server application function or the TURN server application function using the ICE and media configuration parameters, In response to the binding request, means for receiving binding information including quality of service (QoS) and codec data, Means for updating a session description protocol (SDP) offer or answer in accordance with the received binding information, Means for initiating a WebRTC media session in accordance with the updated SDP offer or answer, The device according to claim 8, further comprising the following:

12. The device according to 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 ICE server application function, 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 compatible.

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

14. The device according to claim 8, further comprising means for performing the MSH to receive a list of media configuration recommendations for creating a Session Description Protocol (SDP) offer or answer, wherein the list of media configuration recommendations includes data representing, for each media configuration recommendation, a media type, a codec, an average bitrate, and a maximum bitrate.

15. A computer program comprising instructions, wherein when an instruction is executed by at least one processor of a device for exchanging media data, the instruction causes the at least one processor to perform the method according to any one of claims 1 to 7.

Images