Method and apparatus for mapping DASH to WebRTC transmission

Abstract

Each embodiment includes systems and methods for delivering Hypertext Transfer Protocol (HTTP)-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC). Each embodiment may enable mapping of DASH content onto a WebRTC transport session. Each embodiment may achieve reuse of an encryption context.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority of U.S. Provisional Application No. 63 / 363,707, filed Apr. 27, 2022, entitled “Managing Reordering Timers,” the entire content of which is incorporated herein by reference for all purposes. Background of the Invention

[0003] Long Term Evolution (LTE), 5G New Radio (NR) (5G NR), and other newly developed communication technologies allow wireless devices to communicate information at data rates that are several orders of magnitude greater than those available just a few years ago (e.g., on the order of gigabits per second, etc.).

[0004] Today's communication networks are also more secure, resistant to multipath fading, allow lower network traffic latency, and provide better communication efficiency (e.g., in terms of bits per unit bandwidth used per second, etc.). These and other recent improvements have contributed to the emergence of the Internet of Things (IoT), massive machine-to-machine (M2M) communication systems, autonomous vehicles, and other technologies that rely on continuous and secure communication. Summary of the Invention

[0005] Aspects include systems and methods for delivering Hypertext Transfer Protocol-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC). Aspects may enable mapping DASH content onto a WebRTC transport session. Aspects may implement reuse of an encryption context.

[0006] Aspects may include methods, executed by a processor of an endpoint computing device, to receive Hypertext Transfer Protocol-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC), the methods including: sending a request for a manifest file of the DASH content to a server; and receiving a response to the request from the server, the response including the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content.

[0007] Some aspects may further include: determining one or more DASH content components of the DASH content to be consumed, at least in part, based on parsing the manifest file; selecting WebRTC to receive one or more DASH content components of the DASH content, at least in part, based on an indication that WebRTC is available for delivering the DASH content; and sending a proposal to the server to establish a WebRTC session, the proposal including an indication of one or more DASH content components of the DASH content. Some aspects may further include: receiving, from the server, an acceptance message to establish the WebRTC session, where the acceptance message may include an object indicating a mapping between each respective media stream of the WebRTC session and the DASH components of the one or more DASH components of the DASH content assigned to the respective media stream. Some aspects may further include: receiving the DASH content from the server via at least one respective media stream of the WebRTC session.

[0008] In some aspects, the proposal to establish the WebRTC session may further include an indication of one or more streaming attributes. In some aspects, the one or more streaming attributes are one or more of bandwidth, width, height, frame rate, codec, and file type.

[0009] In some aspects, the indication that WebRTC is available for delivering the DASH content may include an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in the WebRTC session. In some aspects, the indication that WebRTC is available for delivering the DASH content may further include an indication of a signaling protocol for use in establishing the WebRTC session.

[0010] In some aspects, the one or more DASH content components of the DASH content are one or more adaptive sets of the DASH content. In some aspects, the manifest file of the DASH content may be a media presentation description.

[0011] Some aspects may further include: receiving, from the server, an indication of an encryption context between a common encryption and Secure Real-Time Transport Protocol (SRTP) Datagram Transport Layer Security (DTLS) (DTLS-SRTP) that can be reused in the WebRTC session; obtaining a key for the DASH content from an encryption server in response to receiving the indication of the encryption context between the common encryption and DTLS-SRTP that can be reused in the WebRTC session from the server; and decrypting the SRTP packet payload of the DASH content received in the WebRTC session using the obtained key.

[0012] Further aspects include a wireless device having a processor configured with processor-executable instructions for performing the operations of any of the methods outlined above. Further aspects include a wireless device having means for performing the functions of any of the methods outlined above. Further aspects include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of a wireless device to perform the operations of any of the methods outlined above.

[0013] Some aspects include a method performed by a processor of a server to deliver Hypertext Transfer Protocol (HTTP)-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC), the method including: sending a response to a request for a manifest file of the DASH content from an endpoint computing device, where the response can include the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content. In some aspects, the indication that WebRTC can be used to deliver the DASH content can include an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in a WebRTC session. In some aspects, the indication that WebRTC can be used to deliver the DASH content can further include an indication of a signaling protocol for use in establishing the WebRTC session.

[0014] Some aspects can further include: receiving, from the endpoint computing device, a proposal to establish a WebRTC session, the proposal including an indication of one or more DASH content components of the DASH content; establishing the WebRTC session, the WebRTC session including a respective media stream for each of the indicated one or more DASH components of the DASH content; generating an object indicating a mapping between each respective media stream of the WebRTC session and the DASH component assigned to the respective media stream in the DASH content; and sending an acceptance message to establish the WebRTC session to the endpoint computing device, where the acceptance message can include the object indicating the mapping. Some aspects can further include: using at least one respective media stream of the WebRTC session to deliver the DASH content to the endpoint computing device. In some aspects, the proposal from the endpoint computing device to establish the WebRTC session can further include an indication of one or more streaming attributes. In some aspects, the one or more streaming attributes are one or more of bandwidth, width, height, frame rate, codec, and file type.

[0015] In some aspects, the one or more DASH content components of the DASH content are one or more adaptive sets of the DASH content. In some aspects, the manifest file of the DASH content can be a Media Presentation Description.

[0016] Some aspects may further include: determining whether an encryption context between a common encryption and Datagram Transport Layer Security (DTLS) of Secure Real-Time Transport Protocol (SRTP) (DTLS-SRTP) can be reused in the WebRTC session; and in response to determining that the encryption context between the common encryption and DTLS-SRTP can be reused in the WebRTC session: sending an indication to the endpoint computing device that the encryption context between the common encryption and DTLS-SRTP can be reused in the WebRTC session; and delivering the DASH content to the endpoint computing device without applying further encryption.

[0017] Further aspects may include a server having a processor configured to perform one or more operations of any of the methods outlined above. Further aspects include a non-transitory processor-readable storage medium storing processor-executable instructions configured to cause a processor of a network server to perform operations of any of the methods outlined above. Further aspects include a server having means for performing the functions of any of the methods outlined above. Brief Description of the Drawings

[0019] The drawings incorporated herein and constituting a part of this specification illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain the features of the claims.

[0020] Figure 1A is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.

[0021] Figure 1B is a system block diagram illustrating an example decomposed base station architecture of a wireless communication system suitable for implementing any of the various embodiments.

[0022] Figure 2 is a component block diagram illustrating an example computing and wireless modem system suitable for implementing any of the various embodiments.

[0023] Figure 3 is a component block diagram illustrating a software architecture including a radio protocol stack for a user plane and a control plane in wireless communication suitable for implementing any of the various embodiments.

[0024] Figure 4 is a system block diagram of an example Content Delivery Network (CDN) according to various embodiments.

[0025] Figure 5It is a process flow diagram illustrating a method executable by a processor of an endpoint computing device to receive Hypertext Transfer Protocol (HTTP)-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC).

[0026] Figure 6 It is a process flow diagram illustrating a method executable by a processor of a server to deliver DASH content via WebRTC.

[0027] Figure 7 It is a process flow diagram illustrating a method executable by a processor of a server to deliver DASH content via WebRTC.

[0028] Figure 8 It is a process flow diagram illustrating a method executable by a processor of an endpoint computing device to receive DASH content via WebRTC.

[0029] Figure 9 It is a call flow diagram illustrating a method executable by a processor of a server and a processor of an endpoint computing device to receive DASH content via WebRTC.

[0030] Figure 10 It is a component block diagram of a network computing device applicable to various embodiments.

[0031] Figure 11 It is a component block diagram of a computing device applicable to various embodiments.

[0032] Detailed Description

[0033] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts. References to specific examples and embodiments are for illustrative purposes and are not intended to limit the scope of the claims.

[0034] Various embodiments include systems and methods for delivering Hypertext Transfer Protocol (HTTP)-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC). Various aspects enable mapping DASH content onto a WebRTC transport session. DASH can support large-scale content distribution, such as content distributed by a content delivery network (CDN), and WebRTC can support media streaming with near-real-time latency. Mapping DASH content onto a WebRTC transport session according to various embodiments can reduce (e.g., minimize) the end-to-end latency when distributing DASH content, such as live and real-time content. Various embodiments can further enable reuse of encryption contexts, thereby reducing the processing overhead when delivering DASH content.

[0035] The terms "wireless device", "user equipment", and "UE" are used herein to refer to any one or all of the following: an endpoint or user device, including a wireless device, a wireless router device, a radio, a cellular phone, a smartphone, a portable computing device, a personal or mobile multimedia player, a laptop computer, a tablet computer, a smartbook, a superbook, a palmtop computer, a wireless email receiver, an Internet-enabled multimedia cellular phone, medical devices and equipment, biosensors / devices, wearable devices (including smartwatches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings and smart bracelets)), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), Internet of Things (IoT) devices enabled with a wireless network (including smart meters / sensors, industrial manufacturing equipment, large and small machines and appliances for home or enterprise use), wireless communication components within autonomous and semi-autonomous vehicles, UEs added or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices including a memory, wireless communication components, and a programmable processor.

[0036] The term "radio resource" is used herein to refer to hardware, such as a modem, a radio, a processor, a transceiver, a transmitter, a receiver, a timer, a voltage regulator, an oscillator, an amplifier, a filter, an antenna, a circuit, an encoder, a decoder, etc., and / or software that operates individually or in any combination for transmitting and / or receiving electromagnetic radiation to provide wireless communication services (such as cellular and mobile communication services).

[0037] The term "system on a chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC can contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SOC can also include any number of general-purpose and / or dedicated processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). Each SOC can also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0038] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that includes multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SOCs. For example, an SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, an SIP may include one or more multi-chip modules (MCMs) in which multiple ICs or semiconductor dies are encapsulated onto a unified substrate. An SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuitry and encapsulated closely together (such as on a single motherboard or in a single wireless device). The proximity of the SOCs facilitates high-speed communication as well as sharing of memory and resources.

[0039] In various embodiments, the term "server" is used herein to describe any computing device that is capable of acting as a server (such as a main switching server, web server, mail server, document server, content server, or any other type of server). A server may be a dedicated computing device or a computing device that includes a server module (e.g., running an application that enables the computing device to operate as a server). A server module (e.g., a server application) may be a full-featured server module, or a light server module or deputy server module (e.g., a light server application or deputy server application) that is configured to provide synchronization services between dynamic databases on a receiver device. A light server or deputy server may be a scaled-down version of server-type functionality that may be implemented on a receiver device such that the receiver device is able to act as an Internet server (e.g., a corporate email server) only to the extent necessary to provide the functionality described herein.

[0040] As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communication network" may interchangeably refer to a part or all of an operator's wireless network associated with a wireless device and / or a subscription on the wireless device. The techniques described herein may be used in various wireless communication networks such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), FDMA, Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), and other networks. In general, any number of wireless networks may be deployed in a given geographical area. Each wireless network may support at least one radio access technology, which may operate on one or more frequencies or frequency ranges. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including Wideband Code Division Multiple Access (WCDMA) standard), CDMA2000 (including IS-2000, IS-95, and / or IS-856 standards), etc. In another example, a TDMA network may implement Enhanced Data Rates for GSM Evolution (EDGE) for GSM. In another example, an OFDMA network may implement Evolved DURA (E-DURA) (including LTE standard), IEEE 802.11 (WiFi), IEEE 802.16 (WiMAX), IEEE 802.20, etc. References may be made to wireless networks using the LTE standard, and thus the terms "Evolved Universal Terrestrial Radio Access," "E-UTRAN," and "eNodeB" may also be used interchangeably herein to refer to the wireless network. However, such references are provided merely as examples and are not intended to exclude wireless networks using other communication standards.

[0041] LTE is a mobile network standard for 4G wireless communication for high-speed data developed by 3GPP (3rd Generation Partnership Project) and specified in its Release 8 document series. In contrast to the circuit-switched (CS) model of cellular network standards, LTE has been designed to support only packet-switched (PS) services. Data services in LTE may be provided over the Internet, while multimedia services may be supported by the Internet Multimedia Subsystem (IMS) framework. The LTE standard is based on the evolution of Universal Mobile Telecommunications System (UMTS) radio access to Evolved Universal Terrestrial Radio Access Network (E-UTRAN). E-UTRAN together with the Evolved Packet Core (EPC) network (the core network adapted to LTE) constitutes the Evolved Packet System (EPS). The access network in UMTS emulates circuit-switched connections for real-time services and packet-switched connections for data communication services, while the Evolved Packet System (EPS) is purely Internet Protocol (IP)-based, and both real-time services and data communication services are carried by the IP protocol.

[0042] The 5G system is an advanced technology developed from 4G LTE and provides new radio access technology (RAT) through the evolution of the existing mobile communication network structure. The 5G system can support, for example, extended LTE (eLTE) and non-3GPP access (such as WLAN).

[0043] One implementation option that employs advanced networks such as 5G New Radio (NR) (5G NR) networks, networks of future generations of systems (e.g., sixth generation (6G) or higher generation networks, etc.) is the 5G SA network, where the 5G radio access network (RAN) and the 5G core network provide 5G services in a geographical area (such as a country). Thus, the 5G SA network can overlap with the LTE network coverage in a geographical area (such as a country). The 5G SA network can exclusively include NR base stations, such as next-generation Node B (gNodeB or gNB).

[0044] Another implementation option currently employing advanced systems or networks (e.g., 5G systems or networks, 6G systems or networks, higher generation systems or networks, etc.) is the 5G NSA network, where a RAN that provides support for both LTE (also known as 4G) and New Radio (NR) (also known as 5G) (e.g., a RAN that includes both LTE base stations (such as LTE evolved Node B (eNodeB or eNB)) and NR base stations (such as next-generation Node B (gNodeB or gNB))) is connected to an LTE core network (such as an evolved packet core (EPC) network). A wireless device (sometimes referred to as user equipment (UE)) that can support both LTE and NR communication in such a 5G NSA network can signal to the 5G NSA to indicate UE support for dual connectivity with the New Radio (DCNR).

[0045] Web Real-Time Communication (WebRTC) is a protocol that enables real-time peer-to-peer communication between devices. WebRTC uses the Real-Time Transport Protocol (RTP) to transmit media. WebRTC enables the establishment of a WebRTC session between computing devices (such as between an endpoint wireless device and a server (e.g., a server of a CDN network, a game server, a conference server, etc.)), where multiple streams can be supported for data transmission between the devices in the WebRTC session (such as multiple RTP streams being multiplexed over a single IP address and port). In WebRTC, the session establishment protocol may not be defined, although several implementations rely on the Session Initiation Protocol (SIP) session establishment and the Session Description Protocol (SDP) signaling to establish a WebRTC session between devices.

[0046] Hypertext Transfer Protocol (HTTP) streaming is a popular method of delivering content over the Internet. The content becomes available gradually in segments. The segment availability follows a timeline indicating when each contiguous segment becomes available on the HTTP server. The content can be streamed according to a streaming format such as Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS). Streaming formats generally consider two types of main formats, a manifest that provides instructions on where and when to access the segments, and a segment format that includes the actual media content in a downloadable and timed manner. In the case where DASH is focused on below and the term Media Presentation Description (MPD) is used for the manifest, the same concepts may apply to other streaming formats including the manifest and segment formats. As an example, another manifest format may include the Common Media Application Format (CMAF).

[0047] DASH is a standard for implementing HTTP streaming. DASH announces segment availability in a manifest file called a Media Presentation Description (MPD). The MPD is a timeline of segment availability that announces the location of the segments (usually a Uniform Resource Locator (URL) to the HTTP server), the time when the segments are available, and possibly also the size of the segments. A DASH client running on a processor of a computing device (such as a DASH client that provides content to an Adaptive Bitrate (ABR) player) uses the MPD to request and receive segments of the service (such as segments of a media streaming service provided by a CDN server) from the server. The segments of the service described by the MPD can be called presentations, and as such, the term presentation generally can refer to DASH content to be supplied to and / or actually supplied to an endpoint computing device.

[0048] While WebRTC can support peer-to-peer communication, WebRTC currently does not support large-scale content distribution, such as the large-scale distribution of DASH content delivery to endpoint computing devices in various types of content distribution services (such as broadcast services, cloud-based game streaming services, online game spectator mode services, in-venue interaction services, etc.). Specifically, WebRTC has not yet defined how to establish and provide rate adaptation for adaptive bitrate encoding of a DASH session over WebRTC.

[0049] Each embodiment may include systems and methods for delivering DASH content via WebRTC. Each embodiment may enable mapping DASH content onto a WebRTC transport session. In various embodiments, DASH content may be mapped onto a WebRTC transport session to support large-scale content distribution, such as large-scale DASH content delivery to endpoint computing devices in various types of content distribution services (such as broadcast services, cloud-based game streaming services, online game spectator mode services, in-venue interactive services, etc.). In various embodiments, signaling from a server providing content to an endpoint computing device provides and establishes a DASH session via WebRTC. For example, a DASH session including rate adaptation based on adaptive bitrate encoding may be provided and established using a WebRTC session between a server providing DASH content and an endpoint computing device (e.g., a wireless device).

[0050] In various embodiments, a server providing DASH content (such as a CDN edge node server) may signal to an endpoint computing device that the server is capable of supplying DASH content using WebRTC. In various embodiments, a server providing DASH content (such as a CDN edge node server) may receive a request for a manifest of DASH content (e.g., a request for an MPD) from an endpoint computing device. A server providing DASH content (such as a CDN edge node server) may obtain the requested manifest file (e.g., the requested MPD). The requested manifest file (e.g., the requested MPD) may be obtained from memory available to the server or downloaded from another computing device (such as a source server providing DASH content to the CDN).

[0051] In various embodiments, a server that provides DASH content (such as a CDN edge node server) may signal to a requesting endpoint computing device that WebRTC is available for delivering the DASH content, and the server is capable of supplying the DASH content described by the requested manifest (e.g., capable of supplying the presented DASH content described by the requested MPD). The signal to the requesting endpoint computing device that WebRTC is available for delivering the DASH content may include an indication that the server has WebRTC capabilities and an indication of the signaling endpoint (e.g., IP address and port) to be used in the WebRTC session. As an example, the server may respond to a request for a manifest file with a response that includes the requested manifest file, an indication that the server has WebRTC capabilities, and an indication of the signaling endpoint (e.g., IP address and port). The signal to the requesting endpoint computing device that WebRTC is available for delivering the DASH content may include an indication that the server has WebRTC capabilities, an indication of the signaling endpoint (e.g., IP address and port) to be used in the WebRTC session, and an indication of the signaling protocol (e.g., SDP or other suitable protocol) to be used for establishing the WebRTC session.

[0052] As an example, the server may respond to a request for a manifest file with a response that includes the requested manifest file, an indication that the server has WebRTC capabilities, an indication of the signaling endpoint (e.g., IP address and port), and an indication of the signaling protocol (e.g., SDP or other suitable protocol) to be used for establishing the WebRTC session. As an example, a server that provides DASH content (such as a CDN edge node server) may respond to an HTTP GET message for an MPD from a requesting endpoint computing device with an HTTP 200 / OK response message that includes the requested MPD, an indication that the server has WebRTC capabilities (e.g., an element in the HTTP response indicating "WebRTC available"), an indication of the signaling endpoint (e.g., an element in the HTTP response listing the IP address and port to be used in the WebRTC session), and an indication of the signaling protocol (e.g., an element in the HTTP response indicating "SDP") to be used for establishing the WebRTC session.

[0053] In various embodiments, an endpoint computing device that receives, from a server providing DASH content (such as a CDN edge node server), a signal that WebRTC can be used to deliver DASH content may determine to switch to or use WebRTC to receive DASH content. In various embodiments, an endpoint computing device that selects WebRTC to receive DASH content may parse the received manifest file (e.g., parse the received MPD) to determine the DASH content components of the service that will be consumed. For example, an endpoint computing device that selects WebRTC to receive DASH content may parse the received MPD to determine the content components that will be consumed and the corresponding periods and AdaptationSets of these content components.

[0054] In various embodiments, an endpoint computing device that selects WebRTC to receive DASH content may determine streaming attributes associated with the DASH content components of the service that will be consumed. For example, the streaming attributes may include one or more operating points that the endpoint computing device can support for the content components, such as bandwidth (e.g., maximum bandwidth), width / height (e.g., maximum width and / or height), frame rate (e.g., maximum frame rate), etc. For example, the streaming attributes may include the codec and / or file type for the content components. As an example, an endpoint computing device that selects WebRTC to receive DASH content may determine the streaming attributes associated with the DASH content components of each selected AdaptationSet of the service based on the maximum attributes (e.g., @max attributes) indicated in the MPD for each corresponding selected AdaptationSet. Additionally, the endpoint computing device may evaluate its own capabilities to determine the maximum operating points (e.g., maximum bandwidth, maximum width, maximum height, maximum frame rate, etc.) that the endpoint computing device can support for each corresponding selected AdaptationSet, as well as the codec (e.g., @codecs) and file type (e.g., @mimeTypes) of each selected AdaptationSet.

[0055] In various embodiments, an endpoint computing device that selects WebRTC to receive DASH content may send a proposal to establish a WebRTC session to a signaling endpoint (e.g., an IP address and port), such as the signaling endpoint indicated by a server providing the DASH content when providing a manifest file (e.g., MPD) for the DASH content. The proposal to establish a WebRTC session may be sent using a signaling protocol (e.g., SDP) indicated by the server for use in establishing a WebRTC session. In various embodiments, the proposal to establish a WebRTC session may include an indication of the DASH content components to be consumed by the service selected by the endpoint computing device and streaming attributes associated with the DASH content components determined by the endpoint computing device. For example, the proposal to establish a WebRTC session may include one media line per content component, where the maximum capabilities correspond to the streaming attributes determined by the endpoint computing device. For example, the proposal to establish a WebRTC session may include one media line per selected adaptive set and the determined maximum operating points (e.g., maximum bandwidth, maximum width, maximum height, maximum frame rate, etc.) that the endpoint computing device may support for each respective selected adaptive set, the codec (e.g., @codecs) for each selected adaptive set, and the file type (e.g., @mimeTypes).

[0056] In various embodiments, the media stream for a selected DASH content component may be indicated in the proposal to establish a WebRTC session as a receive-only media stream. For example, each media stream in the proposal to establish a WebRTC session may be indicated as "recvonly".

[0057] In various embodiments, a server providing DASH content (such as a CDN edge node server) may receive, at a signaling endpoint (e.g., an IP address and port), a proposal to establish a WebRTC session from an endpoint computing device that selects WebRTC to receive DASH content, and the server is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD). In various embodiments, at least partially based on the proposal to establish a WebRTC session, a server providing DASH content (such as a CDN edge node server) may convert segments of the DASH content into an RTP stream of RTP packets and send the RTP stream to the endpoint computing device. In various embodiments, a server providing DASH content (such as a CDN edge node server) may obtain DASH content (e.g., DASH segments) from a cache and / or a DASH content source, convert the DASH content (e.g., DASH segments) into RTP packets, and send the RTP packets to the endpoint computing device. In various embodiments, an RTP stream may be assigned to each content component (e.g., each adaptation set) indicated in the proposal to establish a WebRTC session received from the endpoint computing device. Additionally, in various embodiments, the CMAF track and segment format may be mapped to one RTP stream (such as an RTP hint track). In various embodiments, a manifest file (such as an MPD) may be used to establish Real-Time Transport Control Protocol (RTCP) synchronization between media streams of different content versions (such as establishing synchronization between media streams of different DASH representations). In various embodiments, a security context may be established for the WebRTC session.

[0058] In various embodiments, once a server providing DASH content (such as a CDN edge node server) establishes a media stream for a WebRTC session, where the server is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD), the server may establish a mapping between the content components of the DASH content selected by the endpoint computing device and the actual media stream used in the WebRTC session to deliver the DASH content. For example, a mapping may be established between the selected presentation of each content component and the actual media stream of the WebRTC session. For example, the label attribute of the SDP may be associated with the @id or label of the selected representation to map the content components of the DASH content selected by the endpoint computing device to the actual media stream used in the WebRTC session to deliver the DASH content.

[0059] In various embodiments, a mapping object may be generated to establish a mapping between the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. The mapping object indicates the assignment of the corresponding content components of the DASH content selected by the endpoint computing device to the actual media streams used in the WebRTC session to deliver the DASH content. As an example, a JavaScript Object Notation (JSON) mapping object may include an indication of the association between the label attributes of the SDP and the @id or label of the selected representation to map the content components of the DASH content selected by the endpoint computing device to the actual media streams used in the WebRTC session to deliver the DASH content. Such an example JSON mapping object may be exchanged between the server and the endpoint computing device to establish and / or update the mapping of the content components of the DASH content selected by the endpoint computing device to the actual media streams used by the server in the WebRTC session to deliver the DASH content.

[0060] A mapping (such as a JSON mapping object) may be sent to the endpoint computing device as part of the initial control message to establish the WebRTC session. For example, a mapping (such as a JSON mapping object) may be sent to the endpoint computing device in the acceptance message that acknowledges the WebRTC session. The acceptance message that acknowledges the WebRTC session may be a response to the offer to establish the WebRTC session.

[0061] Each embodiment may enable the reuse of an encryption context. In each embodiment, a server that provides DASH content (such as a CDN edge node server) may determine whether a selected representation of the DASH content is content-protected, and the server is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD). In response to determining that the selected representation of the DASH content is content-protected, a server that provides DASH content (such as a CDN edge node server) may determine whether an encryption context between a common encryption and Datagram Transport Layer Security (DTLS) with Secure Real-Time Transport Protocol (SRTP) (DTLS-SRTP) can be reused, and the server is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD). For example, when a Data Rights Management (DRM) server encrypts the DASH content before the server that provides DASH content (such as a CDN edge node server) obtains the content, the encryption context between the common encryption and DTLS-SRTP can be reused, and the server that provides DASH content is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD).

[0062] In response to determining that the encryption context between the common encryption and DTLS-SRTP can be reused, the context reuse may be signaled to an endpoint computing device, and an initialization vector may be reused as an element for encryption on the WebRTC session. The endpoint computing device may obtain a key from an encryption server (such as a DRM server) and use the key to decrypt the SRTP packet payload. A server that provides DASH content (such as a CDN edge node server) may use the encryption context with the common encryption and DTLS-SRTP in the WebRTC session to send the DASH content, since the DASH content was initially obtained without re-encrypting the DASH content (e.g., performing re-encryption using the common encryption and DTLS-SRTP), and the server is capable of using WebRTC to deliver the DASH content described by the requested manifest (e.g., capable of delivering the presented DASH content described by the requested MPD). Thus, packets that have been encrypted in the DASH content (such as encrypted using the common encryption and DTLS-SRTP) may not be re-encrypted by the server before being sent to the endpoint computing device.

[0063] Various embodiments improve the operation and efficiency of a communication network and improve the user experience of some applications and services. Mapping DASH content onto a WebRTC transport session according to various embodiments can reduce or minimize the end-to-end latency when distributing DASH content (such as live and real-time content) to an endpoint computing device (e.g., a UE). Reducing (such as minimizing) the end-to-end latency when distributing DASH content according to various embodiments can benefit various services that utilize the delivery of DASH content to users of endpoint computing devices, such as broadcast services, cloud-based game streaming services, online game spectator mode services, in-venue interaction services, and the like. Various embodiments can further enable the reuse of an encryption context, which can eliminate encryption operations performed by a server (such as a CDN edge server), thereby reducing the processing overhead when delivering DASH content to an endpoint computing device. Reducing the processing overhead when delivering DASH content according to various embodiments can benefit various services that utilize the delivery of DASH content to end users, such as broadcast services, cloud-based game streaming services, online game spectator mode services, in-venue interaction services, and the like.

[0064] Figure 1A is a system block diagram illustrating an example communication system 100. The communication system 100 can be a 5G New Radio (NR) network, or any other suitable network (such as a Long Term Evolution (LTE) network). Although Figure 1A a 5G network is illustrated, future networks may include the same or similar elements. Accordingly, references to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.

[0065] The communication system 100 can include a heterogeneous network architecture that includes a core network 140 and various UEs (at Figure 1Ais illustrated as UEs 120a - 120e). The communication system 100 may also include various network devices 143, such as various servers of a content delivery network (CDN) 142, etc. The communication system 100 may also include several base stations (illustrated as BS110a, BS110b, BS110c, and BS110d) and other network entities. A base station is an entity that communicates with a UE and may also be referred to as a B node, an LTE evolved B node (eNodeB or eNB), an access point (AP), a radio head, a transmission reception point (TRP), a new radio base station (NR BS), a 5G B node (NB), a next-generation B node (gNodeB or gNB), etc. Each base station may provide communication coverage for a specific geographical area. In 3GPP, the term "cell" may refer to the coverage area of a base station, the base station subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 may be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, etc.

[0066] Base stations 110a - 110d may provide communication coverage for macro cells, pico cells, femto cells, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographical area (e.g., with a radius of several kilometers) and may allow unconstrained access by UEs with a service subscription. A pico cell may cover a relatively small geographical area and may allow unconstrained access by UEs with a service subscription. A femto cell may cover a relatively small geographical area (e.g., a residence) and may allow constrained access by UEs associated with the femto cell (e.g., UEs in a closed subscriber group (CSG)). The base station for a macro cell may be referred to as a macro BS. The base station for a pico cell may be referred to as a pico BS. The base station for a femto cell may be referred to as a femto BS or a home BS. In Figure 1A the example illustrated, base station 110a may be a macro BS for macro cell 102a, base station 110b may be a pico BS for pico cell 102b, and base station 110c may be a femto BS for femto cell 102c. Base stations 110a - 110d may support one or more (e.g., three) cells. The terms "eNB", "base station", "NR BS", "gNB", "TRP", "AP", "B node", "5G NB", and "cell" may be used interchangeably herein.

[0067] In some examples, a cell may not be stationary, and the geographical area of the cell may move according to the location of the mobile base station. In some examples, base stations 110a - 110d may be interconnected with each other and with one or more other base stations or network nodes (not illustrated) in the communication system 100 using any suitable transport network via various types of backhaul interfaces, such as direct physical connections, virtual networks, or combinations thereof.

[0068] Base stations 110a - 110d may communicate with the core network 140 over a wired or wireless communication link 126. UEs 120a - 120e may communicate with base stations 110a - 110d over a wireless communication link 122.

[0069] The wired communication link 126 may use various wired networks, such as Ethernet, TV cable, telephone, fiber optic, and other forms of physical network connections, which may use one or more wired communication protocols, such as Ethernet, Point - to - Point Protocol, High - Level Data Link Control (HDLC), Advanced Data Communication Control Protocol (ADCCP), and Transmission Control Protocol / Internet Protocol (TCP / IP).

[0070] The communication system 100 may also include relay stations, such as relay BS110d. A relay station is an entity that can receive a transmission of data from an upstream station (e.g., a base station or a UE) and send the transmission of the data to a downstream station (e.g., a UE or a base station). A relay station may also be a wireless device (e.g., a UE) that can relay transmissions for other UEs. In Figure 1A the example illustrated, the relay station 110d may communicate with the macro base station 110a and the UE 120d to facilitate communication between the base station 110a and the UE 120d. A relay station may also be referred to as a relay base station, a relay, etc.

[0071] The communication system 100 may be a heterogeneous network including different types of base stations (e.g., macro base stations, pico base stations, femto base stations, relay base stations, etc.). These different types of base stations may have different transmit power levels, different coverage areas, and different impacts on interference in the communication system 100. For example, a macro base station may have a high transmit power level (e.g., 5 to 40 watts), while pico base stations, femto base stations, and relay base stations may have lower transmit power levels (e.g., 0.1 to 2 watts).

[0072] The network controller 130 may be coupled to a set of base stations and may provide coordination and control of these base stations. The network controller 130 may communicate with the base stations via the backhaul. The base stations may also communicate with each other directly or indirectly, for example, via wireless or wired backhaul.

[0073] UEs 120a, 120b, 120c can be dispersed throughout the communication system 100, and each UE can be stationary or mobile. The UE can also be referred to as an access terminal, terminal, mobile station, subscriber unit, station, wireless device, etc.

[0074] The macro base station 110a can communicate with the communication network 140 over a wired or wireless communication link 126. The UEs 120a, 120b, 120c can communicate with the base stations 110a - 110d over wireless communication links 122.

[0075] The wireless communication links 122 and 124 can include multiple carrier signals, frequencies, or frequency bands, each of which can include multiple logical channels. The wireless communication links 122 and 124 can utilize one or more radio access technologies (RATs). Examples of RATs that can be used in the wireless communication link include: 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, code division multiple access (CDMA), wideband code division multiple access (WCDMA), worldwide interoperability for microwave access (WiMAX), time division multiple access (TDMA), and other cellular RATs for mobile phone communication. Other examples of RATs that can be used in one or more of the various wireless communication links within the communication system 100 include mid - range protocols (such as Wi - Fi, LTE - U, LTE - Direct, LAA, MuLTEfire) and relatively short - range RATs (such as ZigBee, Bluetooth, and Bluetooth low energy (LE)).

[0076] Some wireless networks (e.g., LTE) utilize orthogonal frequency division multiplexing (OFDM) on the downlink and single - carrier frequency - division multiplexing (SC - FDM) on the uplink. OFDM and SC - FDM divide the system bandwidth into multiple (K) orthogonal sub - carriers, which are also often referred to as frequency tones, frequency slots, etc. Each sub - carrier can be modulated with data. Generally, modulation symbols are transmitted in the frequency domain for OFDM and in the time domain for SC - FDM. The spacing between adjacent sub - carriers can be fixed, and the total number (K) of sub - carriers can depend on the system bandwidth. For example, the sub - carrier spacing can be 15 kHz, and the minimum resource allocation (referred to as a "resource block") can be 12 sub - carriers (or 180 kHz). Thus, for a system bandwidth of 1.25, 2.5, 5, 10, or 20 megahertz (MHz), the nominal fast Fourier transform (FFT) size can be equal to 128, 256, 512, 1024, or 2048, respectively. The system bandwidth can also be divided into sub - bands. For example, a sub - band can cover 1.08 MHz (i.e., 6 resource blocks), and for a system bandwidth of 1.25, 2.5, 5, 10, or 20 MHz, there can be 1, 2, 4, 8, or 16 sub - bands, respectively.

[0077] Although the description of some implementations may use terms and examples associated with LTE technology, some implementations may be applicable to other wireless communication systems such as New Radio (NR) or 5G networks. NR can utilize OFDM with cyclic prefix (CP) on both the uplink (UL) and downlink (DL), and includes support for half-duplex operation using time-division duplex (TDD). A single component carrier bandwidth of 100 MHz can be supported. NR resource blocks can span 12 subcarriers with a subcarrier bandwidth of 75 kHz over a duration of 0.1 milliseconds (ms). Each radio frame can include 50 subframes with a length of 10 ms. Thus, each subframe can have a length of 0.2 ms. Each subframe can indicate the link direction for data transmission (i.e., DL or UL), and the link direction of each subframe can be switched dynamically. Each subframe can include DL / UL data as well as DL / UL control data. Beamforming can be supported and the beam direction can be configured dynamically. Multiple-input multiple-output (MIMO) transmission with precoding can also be supported. MIMO configurations in the DL can support up to 8 transmit antennas (multi-layer DL transmission with up to 8 streams) and up to 2 streams per UE. Multi-layer transmission with up to 2 streams per UE can be supported.

[0078] Up to 8 serving cells can be used to support the aggregation of multiple cells. Alternatively, NR can support different air interfaces other than the OFDM-based air interface.

[0079] Some UEs can be considered machine type communication (MTC) UEs, or evolved or enhanced machine type communication (eMTC) UEs. MTC and eMTC UEs include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. A wireless computing platform can provide connectivity to a network (e.g., a wide area network such as the Internet or a cellular network) or provide connectivity to the network, for example, via a wired or wireless communication link. Some UEs can be considered Internet of Things (IoT) devices, or can be implemented as narrowband IoT (NB-IoT) devices. UEs 120a - 120e can be included inside a housing that houses the components of UEs 120a - 120e, such as processor components, memory components, similar components, or combinations thereof.

[0080] Generally, any number of communication systems and any number of wireless networks can be deployed in a given geographical area. Each communication system and wireless network can support a specific radio access technology (RAT) and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, frequency channel, etc. Each frequency can support a single RAT in a given geographical area to avoid interference between communication systems of different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks can be deployed. For example, a 5G non-standalone (NSA) network can use 4G / LTE RAT on the 4G / LTE RAN side of the 5G NSA network and use 5G / NR RAT on the 5G / NR RAN side of the 5G NSA network at the same time. Both the 4G / LTE RAN and the 5G / NR RAN can be connected to each other and connected to the 4G / LTE core network (e.g., evolved packet core (EPC) network) in the 5G NSA network. Other example network configurations can include a 5G standalone (SA) network, in which the 5G / NR RAN is connected to the 5G core network.

[0081] In some implementations, two or more UEs (e.g., illustrated as UEs 120a and 120e) can communicate directly using one or more sidelink channels (e.g., communicate with each other without using base stations 110a-d as intermediaries). For example, UEs 120a-120e can communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (which can include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), mesh networks, or similar networks or combinations thereof. In this case, UEs 120a-120e can perform scheduling operations, resource selection operations, and other operations described elsewhere herein as performed by base stations 110a-110d.

[0082] In some implementations, the CDN 142 may provide content (such as DASH content) to one or more of the UEs 120a - 120e. The content (such as DASH content) may be delivered from one or more servers 143 of the CDN 142 to the UEs 120a - 120e via the core network 140 and the connections 122, 126. One or more servers 143 of the CDN 142 may be node servers. A server 143 in the CDN 142 may be referred to as a source server, which originates the content (such as DASH content) and provides it to other servers 143 of the CDN 142. The content (such as DASH content) may be delivered using various protocols (such as HTTP (e.g., HTTP / 1.1, etc.), WebRTC, etc.). A server 143 in the CDN 142 that provides content (such as DASH content) to the core network 140 may be referred to as an edge node server of the CDN 142. The UEs 120a - 120e that receive content (such as DASH content) from the CDN 142 may be endpoint computing devices. As an example, the CDN 142 may support delivering DASH content to endpoint computing devices (e.g., UEs 120a - 120e), thereby provisioning various services for the endpoint computing devices, such as live video services, broadcast services, cloud - based game streaming services, online game spectator mode services, in - venue interactive services, etc.

[0083] Figure 1B is a system block diagram illustrating the architecture of an exemplary split base station 160, which may be part of a V2X and / or 5G network adapted to convey V2X messages and misbehavior condition information. Referring to Figure 1A and 1B , the split base station 160 architecture may include one or more central units (CUs) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more split base station units (such as a Near - RT RAN Intelligent Controller (RIC) 164 via an E2 link, or a Non - RT RIC 168 associated with a Service Management and Orchestration (SMO) framework 166, or both). The CU 162 may communicate with one or more distributed units (DUs) 170 via corresponding mid - haul links (such as an F1 interface). The DU 170 may communicate with one or more radio units (RUs) 172 via corresponding fronthaul links. The RU 172 may communicate with a corresponding UE 120 via one or more radio frequency (RF) access links. In some implementations, a UE may be served simultaneously by multiple RUs 172.

[0084] Each of these units (i.e., CU 162, DU 170, RU 172), as well as the near-RT RIC 164, non-RT RIC 168, and SMO framework 166, may include one or more interfaces or be coupled to one or more interfaces that are configured to receive or transmit signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of these units, or an associated processor or controller that provides instructions to the communication interfaces of these units, may be configured to communicate with one or more of the other units via the transmission medium. For example, these units may include a wired interface that is configured to receive or transmit signals to one or more of the other units over a wired transmission medium. Additionally, these units may include a wireless interface that may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or transmit signals, or both, to one or more of the other units over a wireless transmission medium.

[0085] In some aspects, CU 162 may host one or more higher layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function may be implemented with an interface that is configured to communicate signals with other control functions hosted by CU 162. CU 162 may be configured to handle user plane functionality (i.e., Central Unit - User Plane (CU-UP)), control plane functionality (i.e., Central Unit - Control Plane (CU-CP)), or a combination thereof. In some implementations, CU 162 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units may communicate bidirectionally with the CU-CP units via an interface (such as an E1 interface). As needed, CU 162 may be implemented to communicate with DU 170 for network control and signaling.

[0086] DU 170 may correspond to a logical unit that includes one or more base station functions to control the operation of one or more RUs 172. In some aspects, DU 170 may host one or more of the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and one or more high Physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation, etc.) at least partially depending on a functional split (such as the functional split defined by the Third Generation Partnership Project (3GPP)). In some aspects, DU 170 may further host one or more low PHY layers. Each layer (or module) may be implemented with an interface that is configured to communicate signals with other layers (and modules) hosted by DU 170 or with the control functions hosted by CU 162.

[0087] The lower layer functionality may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DU 170 may correspond to logical nodes for main memory RF processing functions or low PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.) or both, at least partially based on a functional split (such as a lower layer functional split). In such an architecture, the (s)RU 172 may be implemented to handle over-the-air (OTA) communication with one or more UEs 120. In some implementations, the real-time and non-real-time aspects of control and user plane communication with the (s)RU 172 may be controlled by the corresponding DU 170. In some scenarios, this configuration may enable the (s)DU 170 and CU 162 to be implemented in a cloud-based Radio Access Network (RAN) architecture (such as a vRAN architecture).

[0088] The SMO framework 166 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 166 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 166 may be configured to interact with a cloud computing platform (such as the Open Cloud (O-Cloud) 176) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, the CU 162, DU 170, RU 172, and near RT RIC 164. In some implementations, the SMO framework 166 may communicate with the hardware aspects of the 4G RAN (such as the Open eNB (O-eNB) 174) via the O1 interface. Additionally, in some implementations, the SMO framework 166 may communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166.

[0089] The non-RT RIC 168 can be configured to include logic functions that implement non-real-time control and optimization of RAN elements and resources, AI / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 can be coupled to or communicate with the near-RT RIC 164 (such as via the A1 interface). The near-RT RIC 164 can be configured to include logic functions that implement near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (such as via the E2 interface) that connects one or more CUs 162, one or more DUs 170, or both, and the O-eNB to the near-RT RIC 164.

[0090] In some implementations, to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 can receive parameters or external enrichment information from an external server. Such information can be utilized by the near-RT RIC 164 and can be received from non-network data sources or from network functions at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 can monitor long-term trends and patterns in performance and employ an AI / ML model to perform corrective actions via the SMO framework 166 (such as reconfiguration via O1) or via the creation of RAN management policies (such as A1 policies).

[0091] Figure 2 FIG. is a component block diagram illustrating an example computing and wireless modem system 200 suitable for implementing any of the various embodiments. The various embodiments can be implemented on several single-processor and multi-processor computer systems, including systems-on-chip (SOC) or system-in-packages (SIP).

[0092] Referring to Figure 1A - 2, the illustrated example computing system 200 (which may be a SIP in some embodiments) includes two SOCs 202, 204 coupled to a clock 206, a voltage regulator 208, and a wireless transceiver 266 configured to transmit and receive wireless communications to / from a UE (such as base station 110a) via an antenna (not shown). In some implementations, the first SOC 202 may operate as a central processing unit (CPU) of the UE, which executes instructions by performing arithmetic, logical, control, and input / output (I / O) operations specified by the instructions of a software application. In some implementations, the second SOC 204 may operate as a dedicated processing unit. For example, the second SOC 204 may operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (such as 5 Gbps, etc.), or ultra-high-frequency short-wavelength (such as 28 GHz mmWave spectrum, etc.) communications.

[0093] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor 216, one or more coprocessors 218 (such as a vector coprocessor) connected to one or more of these processors, a memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple millimeter-wave transceivers 256, a memory 258, and various additional processors 260 (such as an application processor, a packet processor, etc.).

[0094] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SOC 202 may include a processor executing a first type of operating system (such as FreeBSD, LINUX, OS X, etc.) and a processor executing a second type of operating system (such as MICROSOFT WINDOWS 10). Additionally, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (such as a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0095] The first and second SOCs 202, 204 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support processors and software clients operating on the UE. The system components and resources 224 or the custom circuitry 222 may also include circuitry for interfacing with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, and the like.

[0096] The first and second SOCs 202, 204 may communicate via an interconnect / bus module 250. The various processors 210, 212, 214, 216, 218 may be interconnected via an interconnect / bus module 226 to one or more memory elements 220, system components and resources 224, and custom circuitry 222, as well as a thermal management unit 232. Similarly, the processor 252 may be interconnected via an interconnect / bus module 264 to a power management unit 254, a millimeter wave transceiver 256, a memory 258, and various additional processors 260. The interconnect / bus modules 226, 250, 264 may include an array of reconfigurable logic gates or implement a bus architecture such as CoreConnect, AMBA, etc. Communication may be provided by a high-performance on-chip network (NoC) such as an advanced interconnect.

[0097] The first or second SOC 202, 204 may further include an input / output module (not illustrated) for communicating with resources external to the SOC such as a clock 206 and a voltage regulator 208. Resources external to the SOC such as the clock 206, voltage regulator 208 may be shared by two or more internal SOC processors / cores.

[0098] In addition to the example SIP 200 discussed above, some implementations may also be implemented in a variety of computing systems that may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0099] Figure 3 is a component block diagram illustrating a software architecture 300 including a radio protocol stack for a user plane and a control plane in wireless communication suitable for implementing any of the various embodiments. Refer to Figure 1A - 3, the UE 320 can implement the software architecture 300 to facilitate communication between the UE 320 (e.g., UE 120a - 120e, 200) and the network device 350 (e.g., network device 142a) of the communication system (e.g., 100). In various embodiments, the layers in the software architecture 300 can form logical connections with the corresponding layers in the software of the network device 350. The software architecture 300 can be distributed among one or more processors (e.g., processors 212, 214, 216, 218, 252, 260). Although described with respect to one radio protocol stack, in a multi - SIM (Subscriber Identity Module) UE, the software architecture 300 can include multiple protocol stacks, each of which can be associated with a different subscriber identity module (SIM) (e.g., in a dual - SIM wireless communication device, two protocol stacks are respectively associated with two SIMs). Although described below with reference to the LTE communication layer, the software architecture 300 can support any one of various standards and protocols for wireless communication, and / or can include additional protocol stacks that support any one of various standards and protocols for wireless communication.

[0100] The software architecture 300 can include a Non - Access Stratum (NAS) 302 and an Access Stratum (AS) 304. The NAS 302 can include functions and protocols that support packet filtering, security management, mobility control, session management, and traffic and signaling between the UE's (one or more) SIMs (such as (one or more) SIMs 204) and its core network 140. The AS 304 can include functions and protocols that support communication between the SIM (such as (one or more) SIMs 204) and entities of the supported access network (such as base stations). Specifically, the AS 304 can include at least three layers (Layer 1, Layer 2, and Layer 3), and each layer can contain various sub - layers.

[0101] In the user plane and the control plane, Layer 1 (L1) of the AS 304 can be the Physical Layer (PHY) 306, which can supervise functions for implementing transmission or reception on the air interface via a wireless transceiver (e.g., 266). Examples of such Physical Layer 306 functions can include Cyclic Redundancy Check (CRC) attachment, decoding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The physical layer can include various logical channels, which include the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH).

[0102] In the user plane and the control plane, the layer 2 (L2) of the AS 304 may be responsible for the link between the UE 320 and the network device 350 on the physical layer 306. In some implementations, the layer 2 may include a media access control (MAC) sublayer 308, a radio link control (RLC) sublayer 310, a packet data convergence protocol (PDCP) 312 sublayer, and a service data adaptation protocol (SDAP) 317 sublayer, and each sublayer forms a logical connection terminated at the network device 350.

[0103] In the control plane, the layer 3 (L3) of the AS 304 may include a radio resource control (RRC) sublayer 3. Although not shown, the software architecture 300 may include additional layer 3 sublayers and various upper layers above layer 3. In some implementations, the RRC sublayer 313 may provide functions including broadcast system information, paging, and establishing and releasing an RRC signaling connection between the UE 320 and the network device 350.

[0104] In various embodiments, the SDAP sublayer 317 may provide a mapping between quality of service (QoS) flows and data radio bearers (DRBs). In some implementations, the PDCP sublayer 312 may provide uplink functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, encryption, and header compression. In the downlink, the PDCP sublayer 312 may provide functions including in-sequence delivery of data packets, duplicate data packet detection, integrity verification, decryption, and header decompression.

[0105] In the uplink, the RLC sublayer 310 may provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, the RLC sublayer 310 functions may include reordering of data packets to compensate for out-of-order reception, reassembly of upper layer data packets, and ARQ.

[0106] In the uplink, the MAC sublayer 308 may provide functions including multiplexing between logical and transport channels, random access procedures, logical channel prioritization, and hybrid ARQ (HARQ) operations. In the downlink, the MAC layer functions may include channel mapping within a cell, demultiplexing, discontinuous reception (DRX), and HARQ operations.

[0107] Although the software architecture 300 may provide the function of transmitting data through a physical medium, the software architecture 300 may further include at least one host layer 314 to provide data transmission services to various applications in the UE 320. In some implementations, the application-specific functions provided by the at least one host layer 314 may provide an interface between the software architecture and the general-purpose processor 206.

[0108] In other implementations, the software architecture 300 may include one or more higher logical layers (such as transport, session, presentation, application, etc.) that provide host layer functionality. For example, in some implementations, the software architecture 300 may include a network layer (such as an Internet Protocol (IP) layer), where logical connections terminate at a Packet Data Network (PDN) Gateway (PGW). In some implementations, the software architecture 300 may include an application layer, where logical connections terminate at another device (such as an end-user device, a server, etc.). In some implementations, the software architecture 300 may further include a hardware interface 316 between the physical layer 306 and communication hardware (such as one or more Radio Frequency (RF) transceivers) in the AS 304.

[0109] Figure 4 is a system block diagram of an example CDN 400 (e.g., CDN 142) according to various embodiments. Referring to Figure 1A - 4 , the CDN 400 may deliver DASH content from the source server 403 via the node servers 404a-b and 405a-405c (e.g., servers 143). The DASH content may be cached at the respective node servers 404a-404b and 405a-405c. The source server 403 may provide the DASH content to the intermediate node servers 404a-404b via HTTP communication (such as HTTP / 1.1 communication). The intermediate node servers 404a-404b may provide the DASH content to the edge node servers 405a-405c via HTTP communication (such as HTTP / 1.1 communication). The edge node servers 405a-405c may be servers that provide peer-to-peer communication of the DASH content from the CDN 400 to the endpoint computing device 406 (e.g., UEs 120a-120e, 200, 300). The endpoint computing device 406 may also be referred to as a client device and may include a media client application (such as a DASH client application) running on a processor, which may consume the DASH content received from the CDN 400. As an example, the CDN 400 may support delivering DASH content to the endpoint computing device 406, thereby provisioning various services for the endpoint computing device 406, such as live video services, broadcast services, cloud-based game streaming services, online game spectator mode services, in-venue interaction services, etc.

[0110] In various embodiments, the edge node server 405b may support delivering DASH content to the endpoint computing device 406 using WebRTC. In this way, the edge node server 405b may use WebRTC to deliver DASH content instead of delivering DASH content to the endpoint computing device 406 via HTTP communication (such as HTTP / 1.1 communication). In some embodiments, the edge node server 405b may indicate support for WebRTC to the endpoint computing device 406. In some embodiments, the endpoint computing device 406 may trigger an update to WebRTC. In some embodiments, the WebRTC-capable edge node server 405b may convert segments of DASH content into an RTP stream based on the endpoint computing device's selection of WebRTC for DASH content delivery. Additionally, in some embodiments, the CMAF track and segment format may be mapped to one RTP stream (such as an RTP hint track). In some embodiments, the MPD may be used to establish Real-Time Transport Control Protocol (RTCP) synchronization between media streams of different content versions (such as establishing synchronization between media streams of different DASH representations). In some embodiments, a security context may be established for the WebRTC session.

[0111] Figure 5 is a process flow diagram illustrating a method 500 executable by a processor of an endpoint computing device to receive DASH content via WebRTC according to various embodiments. Referring to Figure 1A - 5 FIG. 6, the method 500 may be implemented by one or more processors (such as one or more processors 210, 212, 214, 216, 218, 252, 260, 426) of an endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0112] In block 502, the processor may perform an operation including sending a request for a manifest file of DASH content to a server. As an example, the request for the manifest file of DASH content may be an HTTP GET request for the MPD of the DASH content. The means for performing the function of the operation in block 502 may be one or more processors (such as one or more processors 210, 212, 214, 216, 218, 252, 260, 426, and / or the wireless transceiver 266) of an endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0113] At block 504, the processor may perform operations including receiving a reply to the request from the server, the reply including a manifest file for the DASH content and an indication that WebRTC can be used to deliver the DASH content. In various embodiments, a server that provides DASH content (such as a CDN edge node server) may signal to a requesting endpoint computing device that WebRTC can be used to deliver DASH content, the server being capable of supplying the DASH content described by the requested manifest (e.g., being capable of supplying the presented DASH content described by the requested MPD). As an example, a server that provides DASH content (such as a CDN edge node server) may respond to an HTTP GET message for an MPD from a requesting endpoint computing device with an HTTP 200 / OK response message that includes the requested MPD and an indication that the server has WebRTC capabilities (e.g., an element in the HTTP response indicating "WebRTC available"). In some embodiments, the reply may include additional indications, such as an indication of a signaling endpoint (e.g., an IP address and port) to be used in the WebRTC session and / or an indication of a signaling protocol (e.g., SDP or other suitable protocol) to be used for establishing the WebRTC session. As an example, a server that provides DASH content (such as a CDN edge node server) may respond to an HTTP GET message for an MPD from a requesting endpoint computing device with an HTTP 200 / OK response message that includes the requested MPD, an indication that the server has WebRTC capabilities (e.g., an element in the HTTP response indicating "WebRTC available"), an indication of the signaling endpoint (e.g., an element in the HTTP response listing the IP address and port to be used in the WebRTC session), and an indication of the signaling protocol to be used for establishing the WebRTC session (e.g., an element in the HTTP response indicating "SDP"). The means for performing the functions of the operations in block 504 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266) of an endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0114] At block 506, the processor may perform operations including determining, at least in part based on parsing the manifest file, one or more DASH content components of the DASH content to be consumed. In various embodiments, the endpoint computing device may parse the received manifest file (e.g., parse the received MPD) to determine the DASH content components of the service to be consumed. For example, the endpoint computing device may parse the received MPD to determine the content components to be consumed of the service and the corresponding time periods and adaptation sets of these content components. The means for performing the functions of the operations in block 506 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, etc.) of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0115] At block 508, the processor may perform operations including selecting WebRTC to receive one or more DASH content components of the DASH content, at least in part based on an indication that WebRTC is available for delivering the DASH content. For example, the endpoint computing device may determine to switch to or use WebRTC to receive the DASH content. The means for performing the functions of the operations in block 508 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, etc.) of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0116] At block 510, the processor may perform operations including sending a proposal to establish a WebRTC session to the server, the proposal including an indication of one or more DASH content components of the DASH content. In various embodiments, an endpoint computing device that selects WebRTC to receive DASH content may send a proposal to establish a WebRTC session to a signaling endpoint (e.g., an IP address and port), such as the signaling endpoint indicated by the server providing the DASH content in the manifest file (e.g., MPD) providing the DASH content. The proposal to establish a WebRTC session may be sent using a signaling protocol (e.g., SDP) indicated by the server for use in establishing a WebRTC session. The means for performing the functions of the operations in block 510 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266) of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0117] In some embodiments, a proposal to establish a WebRTC session may additionally include an indication of streaming attributes associated with a DASH content component determined by the endpoint computing device. In some embodiments, an endpoint computing device that selects WebRTC to receive DASH content may determine streaming attributes associated with DASH content components of the service that are to be consumed. For example, the streaming attributes may include one or more operating points of the content component that the endpoint computing device can support, such as bandwidth (e.g., maximum bandwidth), width / height (e.g., maximum width and / or height), frame rate (e.g., maximum frame rate), etc. For example, the streaming attributes may include a codec and / or file type for use with the content component.

[0118] As an example, an endpoint computing device that selects WebRTC to receive DASH content may determine streaming attributes associated with DASH content components of each respective selected adaptation set of the service to be consumed based on the maximum attributes (e.g., @max attributes) indicated in the MPD for each respective selected adaptation set and the capabilities of the endpoint computing device itself, to determine the maximum operating points (e.g., maximum bandwidth, maximum width, maximum height, maximum frame rate, etc.) that the endpoint computing device can support for each respective selected adaptation set, as well as the codec (e.g., @codecs) and file type (e.g., @mimeTypes) of each selected adaptation set. For example, a proposal to establish a WebRTC session may include one media line per content component, where the maximum capabilities correspond to the streaming attributes determined by the endpoint computing device. For example, a proposal to establish a WebRTC session may include one media line per selected adaptation set and the determined maximum operating points (e.g., maximum bandwidth, maximum width, maximum height, maximum frame rate, etc.) that the endpoint computing device can support for each respective selected adaptation set, the codec (e.g., @codecs) and file type (e.g., @mimeTypes) of each selected adaptation set.

[0119] In some embodiments, the media stream for a selected DASH content component may be indicated in a proposal to establish a WebRTC session as a receive-only media stream. For example, each media stream in a proposal to establish a WebRTC session may be indicated as "receive-only".

[0120] At block 512, the processor may perform an operation including receiving, from the server, an acceptance message for establishing a WebRTC session, where the acceptance message includes an object indicating a mapping between each respective media stream of the WebRTC session and a DASH component assigned to the respective media stream among one or more DASH components of the DASH content. In various embodiments, once the server has established the media streams of a WebRTC session, the server may establish a mapping between the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. For example, a mapping may be established between the selected presentation of each content component and the actual media streams of the WebRTC session. For example, the label attributes of the SDP may be associated with the @id or label of the selected representation to map the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. As an example, a JavaScript Object Notation (JSON) mapping object may include an indication of the association between the label attributes of the SDP and the @id or label of the selected representation to map the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. Such an example JSON mapping object may be exchanged between the server and the endpoint computing device to establish and / or update the mapping of the content components of the DASH content selected by the endpoint computing device and the actual media streams used by the server in the WebRTC session to deliver the DASH content. The mapping (such as the JSON mapping object) may be sent to the endpoint computing device as part of the initial control message for establishing the WebRTC session. For example, the mapping (such as the JSON mapping object) may be sent to the endpoint computing device in the acceptance message confirming the WebRTC session. The acceptance message confirming the WebRTC session may be a response to a proposal to establish the WebRTC session. The means for performing the functions of the operations in block 512 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or the wireless transceiver 266) of an endpoint computing device (such as 120a - 120e, 200, 300, 406).

[0121] At block 514, the processor may perform operations including receiving the DASH content from the server via at least one respective media stream of the WebRTC session. In various embodiments, a server providing DASH content may obtain DASH content (e.g., DASH segments) from a cache and / or a DASH content source, convert the DASH content (e.g., DASH segments) into RTP packets, and send the RTP packets to the endpoint computing device. In some embodiments, an RTP stream may be assigned to each content component (e.g., each adaptation set) indicated in a proposal to establish a WebRTC session received from the endpoint computing device. Additionally, in some embodiments, the CMAF tracking and segmentation format may be mapped to one RTP stream (such as an RTP cue track). In some embodiments, a manifest file (such as an MPD) may be used to establish Real-Time Transport Control Protocol (RTCP) synchronization between media streams of different content versions (such as establishing synchronization between media streams of different DASH representations). In some embodiments, a security context may be established for the WebRTC session. The means for performing the functions of the operations in block 514 may be one or more processors (such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266) of an endpoint computing device (e.g., 120a - 120e, 200, 300, 406).

[0122] Figure 6 is a process flow diagram illustrating a method 600 executable by a processor of a server to deliver DASH content via WebRTC according to various embodiments. Referring to Figure 1A - 6 , method 600 may be implemented by one or more processors of a server (e.g., 143, 405b, etc.). In various embodiments, the operations of method 600 may be performed in conjunction with the operations of method 500.

[0123] At block 602, the processor may perform operations including receiving a request for a manifest file of DASH content from an endpoint computing device (e.g., 120a - 120e, 200, 300, 406). As an example, a request for a manifest file of DASH content may be an HTTP GET request for an MPD of the DASH content. The means for performing the functions of the operations in block 602 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0124] At block 604, the processor may perform operations including obtaining the manifest file or the DASH content. The requested manifest file (e.g., the requested MPD) may be obtained from the memory available to the server or downloaded from another computing device (such as a source server that provides DASH content to a CDN). The means for performing the functions of the operations in block 604 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0125] At block 606, the processor may perform operations including sending a reply to a request for a manifest file of DASH content from an endpoint computing device, where the reply includes the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content. The means for performing the functions of the operations in block 606 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0126] As an example of the operations in block 606, a server that provides DASH content (such as a CDN edge node server) may respond to an HTTP GET message for an MPD from a requesting endpoint computing device with an HTTP 200 / OK response message that includes the requested MPD and an indication that the server has WebRTC capabilities (e.g., an element in the HTTP response indicating "WebRTC available"). As another example, the server may respond to a request for a manifest file with a response that includes the requested manifest file, an indication that the server has WebRTC capabilities, and an indication of a signaling endpoint (e.g., an IP address and port).

[0127] In some embodiments, the signal sent by the server to the requesting endpoint computing device regarding that WebRTC can be used to deliver the DASH content in box 606 may include an indication that the server has WebRTC capabilities, an indication of the signaling endpoint (e.g., IP address and port) to be used in the WebRTC session, and an indication of the signaling protocol (e.g., SDP or other suitable protocol) to be used for establishing the WebRTC session. As an example, a server providing DASH content (such as a CDN edge node server) may respond to an HTTP GET message for the MPD from the requesting endpoint computing device with an HTTP 200 / OK response message that includes the requested MPD, an indication that the server has WebRTC capabilities (e.g., an element in the HTTP response indicating "WebRTC available"), an indication of the signaling endpoint (e.g., an element in the HTTP response listing the IP address and port to be used in the WebRTC session), and an indication of the signaling protocol to be used for establishing the WebRTC session (e.g., an element in the HTTP response indicating "SDP").

[0128] At block 608, the processor may perform an operation including receiving, from the endpoint computing device, a proposal to establish a WebRTC session, the proposal including an indication of one or more DASH content components of the DASH content. In some embodiments, an endpoint computing device that selects WebRTC to receive DASH content may send a proposal to establish a WebRTC session to a signaling endpoint (e.g., an IP address and port). The proposal to establish a WebRTC session may be sent using a signaling protocol (e.g., SDP) indicated by the server for use in establishing a WebRTC session. In some embodiments, the proposal to establish a WebRTC session may include an indication of the DASH content components selected by the endpoint computing device that are to be consumed by the service and streaming attributes associated with the DASH content components determined by the endpoint computing device. For example, the proposal to establish a WebRTC session may include one media line per content component, where the maximum capabilities correspond to the streaming attributes determined by the endpoint computing device. For example, the proposal to establish a WebRTC session may include one media line per selected adaptive set and the determined maximum operating points (e.g., maximum bandwidth, maximum width, maximum height, maximum frame rate, etc.) that the endpoint computing device may support for each respective selected adaptive set, the codec (e.g., @codecs) for each selected adaptive set, and the file type (e.g., @mimeTypes). In some embodiments, the media streams for the selected DASH content components may be indicated in the proposal to establish a WebRTC session as receive-only media streams. For example, each media stream in the proposal to establish a WebRTC session may be indicated as "receive-only". The means for performing the functions of the operations in block 608 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0129] At block 610, the processor may perform an operation including establishing a WebRTC session that includes a respective media stream for each of the indicated one or more DASH components for the DASH content. In various embodiments, establishing the WebRTC session may include assigning a media stream to each DASH component indicated as selected by the endpoint computing device for the DASH content. The means for performing the functions of the operations in block 610 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0130] At block 612, the processor may perform operations including generating an object that indicates a mapping between each respective media stream of the WebRTC session and the DASH components assigned to the respective media stream in the DASH content. In various embodiments, once the media streams of the WebRTC session are established, the server may establish a mapping between the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. For example, a mapping may be established between the selected presentation of each content component and the actual media streams of the WebRTC session. For example, the tag attributes of the SDP may be associated with the @id or tag of the selected representation to map the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. The means for performing the functions of the operations in block 612 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0131] In some embodiments, the mapping between the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content may be established at block 612 by generating a mapping object that indicates the assignment of the respective content components of the DASH content selected by the endpoint computing device to the actual media streams used in the WebRTC session to deliver the DASH content. As an example, a JavaScript Object Notation (JSON) mapping object may include an indication of the association between the tag attributes of the SDP and the @id or tag of the selected representation to map the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session to deliver the DASH content. Such an example JSON mapping object may be exchanged between the server and the endpoint computing device to establish and / or update the mapping of the content components of the DASH content selected by the endpoint computing device and the actual media streams used in the WebRTC session for the server to deliver the DASH content.

[0132] At block 614, the processor may perform operations including sending an acceptance message for establishing the WebRTC session to the endpoint computing device, where the acceptance message includes an object indicating the mapping. The mapping (such as a JSON mapping object) may be sent to the endpoint computing device as part of an initial control message for establishing the WebRTC session. For example, the mapping (such as a JSON mapping object) may be sent to the endpoint computing device in an acceptance message for confirming the WebRTC session. The acceptance message for confirming the WebRTC session may be a response to a proposal to establish the WebRTC session. The means for performing the functions of the operations in block 614 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0133] At block 616, the processor may perform operations including delivering the DASH content to the endpoint computing device using at least one respective media stream of the WebRTC session. In various embodiments, the server may convert segments of the DASH content into an RTP stream of RTP packets and send the RTP stream to the endpoint computing device. In some embodiments, the server may obtain DASH content (e.g., DASH segments) from a cache and / or a DASH content source, convert the DASH content (e.g., DASH segments) into RTP packets, and send the RTP packets to the endpoint computing device. In some embodiments, an RTP stream may be assigned to each content component (e.g., each adaptive set) indicated in a proposal to establish a WebRTC session received from the endpoint computing device. Additionally, in some embodiments, the CMAF track and segment format may be mapped to one RTP stream, such as an RTP cue track. In various embodiments, a manifest file (such as an MPD) may be used to establish Real-Time Transport Control Protocol (RTCP) synchronization between media streams of different content versions (such as establishing synchronization between media streams of different DASH representations). In various embodiments, a security context may be established for the WebRTC session. The means for performing the functions of the operations in block 616 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0134] Figure 7 is a process flow diagram illustrating a method 700 executable by a processor of a server to deliver DASH content via WebRTC according to various embodiments. Referring to Figure 1A - 7 , method 700 may be implemented by one or more processors of a server (e.g., 143, 405b, etc.). In various embodiments, the operations of method 700 may be performed in conjunction with the operations of method 500 and / or 600. As an example, the operations of method 700 may be performed as part of the operation of delivering DASH content to the endpoint computing device in block 616 of method 600.

[0135] In response to sending an acceptance message to establish the WebRTC session in block 614, the processor may perform operations including determining, in decision block 702, whether an encryption context between common encryption and DTLS-SRTP may be reused in the WebRTC session. For example, when a Data Rights Management (DRM) server encrypts the DASH content before the server obtains the content, the encryption context between common encryption and DTLS-SRTP may be reused. The means for performing the functions of the operations in block 702 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0136] In response to determining that the encryption context between common encryption and DTLS - SRTP cannot be reused in the WebRTC session (i.e., determining that box 702 = "No"), the processor may perform the operations in box 614 of method 600, as described.

[0137] In response to determining that the encryption context between common encryption and DTLS - SRTP can be reused in the WebRTC session (i.e., determining that box 702 = "Yes"), the processor may perform operations including sending an indication to the endpoint computing device in box 704 that the encryption context between common encryption and DTLS - SRTP can be reused in the WebRTC session. For example, context reuse may be signaled to the endpoint computing device, and the initialization vector may be reused as an element for encryption on the WebRTC session. The means for performing the functions of the operations in box 704 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0138] In box 706, the processor may perform operations including delivering the DASH content to the endpoint computing device without applying further encryption. For example, the processor may perform operations including delivering the DASH content to the endpoint computing device without applying a further encryption context between common encryption and DTLS - SRTP. The server may use the encryption context with common encryption and DTLS - SRTP to send the DASH content in the WebRTC session because the DASH content was initially obtained without re - encrypting the DASH content (e.g., using separate common encryption and DTLS - SRTP). Thus, packets that are already encrypted in the DASH content (such as using common encryption and DTLS - SRTP or other suitable encryption) may not be re - encrypted by the server before being sent to the endpoint computing device. The means for performing the functions of the operations in box 706 may be one or more processors of a server (e.g., 143, 405b, etc.).

[0139] Figure 8 is a process flow diagram illustrating method 800 that may be performed by a processor of an endpoint computing device to receive DASH content via WebRTC according to various embodiments. Referring to Figure 1A - 5 Method 500 may be implemented by one or more processors (e.g., 210, 212, 214, 216, 218, 252, 260, 426) of an endpoint computing device (e.g., 120a - 120e, 200, 300, 406). In various embodiments, the operations of method 800 may be performed in conjunction with the operations of methods 500, 600, and / or 700. As an example, the operations of method 800 may be performed in response to receiving an acceptance message in box 512 of method 500.

[0140] At block 802, the processor may perform operations including receiving an indication from a server regarding the reuse of an encryption context between common encryption and DTLS - SRTP in a WebRTC session. For example, context reuse may be signaled to the endpoint computing device, and an initialization vector may be reused as an element for encryption on the WebRTC session. The means for performing the functions of the operations in block 802 may be one or more processors of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406) such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266.

[0141] At block 804, the processor may perform operations including obtaining a key for the DASH content from an encryption server in response to receiving an indication from the server regarding the reuse of an encryption context between common encryption and DTLS - SRTP in a WebRTC session. The endpoint computing device may obtain the key from an encryption server (such as a DRM server) and use the key to decrypt the SRTP packet payload. The means for performing the functions of the operations in block 804 may be one or more processors of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406) such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266.

[0142] At block 514, the processor may perform the operation of receiving DASH content, as discussed with reference to method 500.

[0143] At block 806, the processor may perform operations including decrypting the SRTP packet payload of the DASH content received in the WebRTC session using the obtained key. Thus, the packets of the DASH content may be decrypted using the obtained key without having to use a separate key from the server that sent the DASH content in the WebRTC session. The means for performing the functions of the operations in block 806 may be one or more processors of the endpoint computing device (e.g., 120a - 120e, 200, 300, 406) such as one or more of processors 210, 212, 214, 216, 218, 252, 260, 426, and / or wireless transceiver 266.

[0144] Figure 9 illustrates that according to various embodiments, it can be performed by endpoint computing device 902 (e.g., 120a - 120e, 200, 300, 406) (in Figure 9Call flow diagram of a method executed by a processor (labeled as "client" in Figure 1A - 9 , Figure 9 to receive DASH content via WebRTC. Refer to Figure 9 for an example interaction between a CDN edge node server 903 (e.g., 143, 405b) (labeled as "CDN edge server" in Figure 9 ), an endpoint computing device 902, and a source server 904 (e.g., 403) (labeled as "source" in Figure 9 . The example interaction may be an example operation performed according to one or more of methods 500, 600, 700, and / or 800.

[0145] In communication 1, the endpoint computing device 902 may send an HTTP GET request for the MPD of the DASH content to the CDN edge node server 903. The CDN edge node server 903 may reply with an HTTP response 200 / OK with the MPD in communication 2. The HTTP response 200 / OK may include an indication that the CDN edge node server 903 has WebRTC capabilities and indicate the control endpoint (e.g., endpoint IP address and port). In communication 3, the endpoint computing device 902 may establish a WebRTC session by sending an SDP offer with a mapping of DASH content components to be streamed from the CDN edge node server 903. In communication 4, the CDN edge node server 903 may send an acceptance message for the WebRTC session as a reply to the endpoint computing device 902. The acceptance may include an object indicating the mapping between each corresponding media stream of the WebRTC session and the DASH component assigned to that corresponding media stream in the DASH content.

[0146] In communication 5, the CDN edge node server 903 may determine a reusable encryption context. In communication 6, the CDN edge node server 903 may signal the encryption context reuse to the endpoint computing device 902. In communication 7, the endpoint computing device 902 may obtain an encryption key from the source server (e.g., a DRM server provides the key as part of a DASH content license). In communication 8, the endpoint computing device 902 and the CDN edge node server 903 may establish a DTLS-SRTP encryption context. In communication 9, the CDN edge node server 903 may obtain DASH segments from a cache or the source server 904. In communication 10, the CDN edge node server 903 may convert the DASH segments into RTP packets. In communication 11, the CDN edge node server 903 may send the RTP packets to the endpoint computing device 902.

[0147] Figure 10 is a component block diagram of a network computing device 1000 (such as a server) applicable to each embodiment. Referring to Figure 1A - 10 , each embodiment can be implemented on various network computing devices 1000 (e.g., base stations 110a - e, 350, servers 143, CDN edge node servers 405a - 405c, CDN node servers 404a - 404b, origin servers 403, 904, etc.), examples of which are Figure 10 illustrated in the form of a server. Such network computing devices may at least include Figure 10 the components illustrated in. The network computing device 1000 may include: a processor 1001, which is coupled to a volatile memory 1002 and a large - capacity non - volatile memory (such as a disk drive 1008). The network computing device 1000 may also include: a peripheral memory access device (such as a floppy disk drive, a compact disc (CD) or a digital video disc (DVD) drive 1006) coupled to the processor 1001. The network computing device 1000 may also include: a network access port 1004 (or interface) coupled to the processor 1001 for establishing a data connection with a network (such as the Internet and / or a local area network coupled to other system computers and servers). The network computing device 1000 may include: one or more antennas 1007 for transmitting and receiving electromagnetic radiation, and the one or more antennas 1007 may be connected to a wireless communication link. The network computing device 1000 may include: additional access ports for coupling to peripheral devices, external memories or other devices, such as USB, Firewire, Thunderbolt, etc.

[0148] Figure 11 is a component block diagram of a computing device (such as an endpoint computing device) applicable to each embodiment. Referring to Figure 1A - 11 , each embodiment can be implemented on various computing devices (such as endpoint computing devices (e.g., UEs 120a - 120e, wireless devices 200, 320, endpoint computing devices 406, 902, etc.)), examples of which are Figure 11is illustrated in the form of a wireless device 1100. The wireless device 1100 may include: a first SOC 202 (e.g., SOC-CPU), which is coupled to a second SOC 204 (e.g., a SOC with 5G capabilities). The first and second SOCs 202, 204 may be coupled to an internal memory 1116, a display 1112, and a speaker 1114. Additionally, the wireless device 1100 may include: an antenna 1104 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266, and the wireless transceiver 266 is coupled to one or more processors in the first and / or second SOCs 202, 204. The wireless device 1100 may further include: a menu selection button or rocker switch 1120 for receiving user input.

[0149] The wireless device 1100 further includes: a sound codec (CODEC) circuit 1110, which digitizes the sound received from a microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal provided to the speaker to produce sound. Additionally, one or more of the processors in the first and second SOCs 202, 204, the wireless transceiver 266, and the CODEC 1110 may include: a digital signal processor (DSP) circuit (not shown separately).

[0150] The processors of the network computing device 1000 and the wireless device 1100 may be any programmable microprocessor, microcomputer, or one or more multiprocessor chips that can be configured by software instructions (applications) to perform various functions including the functions of the various embodiments described below. In some mobile devices, multiple processors may be provided (such as one processor dedicated to wireless communication functions within the SOC 204 and one processor dedicated to running other applications within the SOC 202). Software applications may be stored in the memory and then accessed and loaded into the processor. The processor may include an internal memory sufficient to store the software application instructions.

[0151] As used in this application, the terms "component", "module", "system" and like terms are intended to include computer-related entities such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a wireless device and the wireless device can be referred to as components. One or more components can reside within a process and / or thread of execution, and a component can be localized on one processor or core and / or distributed between two or more processors or cores. Additionally, these components can execute from various non-transitory computer-readable media having various instructions and / or data structures stored thereon. The components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process-related communication methodologies.

[0152] Several different cellular and mobile communication services and standards are available and envisioned for the future, all of which can be implemented and benefit from various embodiments. Such services and standards include, for example, the Third Generation Partnership Project (3GPP), LTE systems, Third Generation Wireless Mobile Communication Technology (3G), Fourth Generation Wireless Mobile Communication Technology (4G), Fifth Generation Wireless Mobile Communication Technology (5G) and future 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rate for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any reference to terms and / or technical details related to an individual telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the claim language.

[0153] The various embodiments described and depicted are provided only as examples to illustrate the various features of the claims. However, the features shown and described for any given embodiment need not be limited to the associated embodiment and may be used in conjunction with or combined with the other embodiments shown and described. Additionally, the claims are not intended to be limited to any one example embodiment. For example, one or more operations of methods 500, 600, 700, and / or 800 may replace or be combined with one or more operations of methods 500, 600, 700, and / or 800.

[0154] Example implementations are described in the following paragraphs. Although some of the following example implementations are described in the form of example methods, further example implementations may include: example methods implemented by a computing device, the computing device including a processor configured to perform the operations of these example methods; example methods implemented by a computing device, the computing device including means for performing the functions of these example methods; and example methods implemented as a non-transitory processor-readable storage medium storing processor-executable instructions, the processor-executable instructions being configured to cause a processor of the computing device to perform the operations of these example methods.

[0155] Example 1. A method performed by a processor of an endpoint computing device to receive Hypertext Transfer Protocol-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC), the method comprising: sending a request for a manifest file of the DASH content to a server; and receiving a reply to the request from the server, the reply including the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content.

[0156] Example 2. The method of Example 1, further comprising: determining, at least in part based on parsing the manifest file, one or more DASH content components of the DASH content to be consumed; selecting WebRTC to receive one or more DASH content components of the DASH content, at least in part based on the indication that WebRTC can be used to deliver the DASH content; and sending a proposal to establish a WebRTC session to the server, the proposal including an indication of one or more DASH content components of the DASH content.

[0157] Example 3. The method of Example 2, further comprising: receiving an acceptance message to establish the WebRTC session from the server, wherein the acceptance message includes an object indicating a mapping between each respective media stream of the WebRTC session and the DASH components of the one or more DASH components of the DASH content assigned to the respective media stream.

[0158] Example 4. The method of Example 3 further includes: receiving the DASH content from the server via at least one corresponding media stream of the WebRTC session.

[0159] Example 5. The method of any one of Examples 1-4, wherein the offer to establish the WebRTC session further includes an indication of one or more streaming attributes.

[0160] Example 6. The method of Example 5, wherein the one or more streaming attributes are one or more of bandwidth, width, height, frame rate, codec, and file type.

[0161] Example 7. The method of any one of Examples 1-6, wherein the indication that WebRTC can be used to deliver the DASH content includes an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in the WebRTC session.

[0162] Example 8. The method of Example 7, wherein: the indication that WebRTC can be used to deliver the DASH content further includes an indication of a signaling protocol for use in establishing the WebRTC session.

[0163] Example 9. The method of any one of Examples 1-8, wherein one or more DASH content components of the DASH content are one or more adaptive sets of the DASH content.

[0164] Example 10. The method of any one of Examples 1-9, wherein the manifest file of the DASH content is a media presentation description.

[0165] Example 11. The method of any one of Examples 1-10 further includes: receiving from the server an indication of an encryption context between a common encryption and Datagram Transport Layer Security (DTLS) - Secure Real-Time Protocol (SRTP) (DTLS-SRTP) that can be reused in the WebRTC session; obtaining a key for the DASH content from an encryption server in response to receiving from the server an indication of an encryption context between the common encryption and DTLS-SRTP that can be reused in the WebRTC session; and decrypting the SRTP packet payload of the DASH content received in the WebRTC session using the obtained key.

[0166] Example 12. A method performed by a processor of a server to deliver Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) content via Web Real-Time Communication (WebRTC), including: sending a response to a request for a manifest file of DASH content from an endpoint computing device, where the response includes the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content.

[0167] Example 13. The method of Example 12, wherein: the indication that WebRTC can be used to deliver the DASH content includes an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in a WebRTC session.

[0168] Example 14. The method of Example 13, wherein: the indication that WebRTC can be used to deliver the DASH content further includes an indication of a signaling protocol for use in establishing the WebRTC session.

[0169] Example 15. The method of any one of Examples 12-14, further including: receiving, from the endpoint computing device, a proposal to establish a WebRTC session, the proposal including an indication of one or more DASH content components of the DASH content; establishing the WebRTC session, the WebRTC session including a corresponding media stream for each of the indicated one or more DASH components of the DASH content; generating an object indicating a mapping between each corresponding media stream of the WebRTC session and the DASH component assigned to the corresponding media stream in the DASH content; and sending an acceptance message to establish the WebRTC session to the endpoint computing device, where the acceptance message includes the object indicating the mapping.

[0170] Example 16. The method of Example 15, further including: using at least one corresponding media stream of the WebRTC session to deliver the DASH content to the endpoint computing device.

[0171] Example 17. The method of any one of Examples 15-16, wherein the proposal from the endpoint computing device to establish the WebRTC session further includes an indication of one or more streaming attributes.

[0172] Example 18. The method of Example 17, wherein: the one or more streaming attributes are one or more of bandwidth, width, height, frame rate, codec, and file type.

[0173] Example 19. The method of any one of Examples 15-18, wherein the one or more DASH content components of the DASH content are one or more adaptive sets of the DASH content.

[0174] Example 20. A method as in any of Examples 12 - 19, wherein the manifest file of the DASH content is a media presentation description.

[0175] Example 21. A method as in any of Examples 12 - 20, further comprising: determining whether an encryption context between a common encryption and Datagram Transport Layer Security (DTLS) - Secure Real - Time Transport Protocol (SRTP) (DTLS - SRTP) can be reused in the WebRTC session; and in response to determining that the encryption context between the common encryption and DTLS - SRTP can be reused in the WebRTC session: sending an indication to the endpoint computing device that the encryption context between the common encryption and DTLS - SRTP can be reused in the WebRTC session; and delivering the DASH content to the endpoint computing device without applying further encryption.

[0176] The foregoing method descriptions and process flow diagrams are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "subsequently," "then," etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. Further, any reference to an element in the singular form of a claim (e.g., a reference using the articles "a," "an," or "the") should not be construed as limiting the element to the singular.

[0177] The various illustrative logical blocks, modules, components, circuits, and algorithmic operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and operations are described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and the design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0178] Hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented using a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver intelligent objects, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry dedicated to a given function.

[0179] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. Operations of a method or algorithm disclosed herein may be implemented in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or a processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage intelligent objects, 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. 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 generally reproduces data magnetically and disc uses lasers optically to reproduce data. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, operations of a method or algorithm may reside as one or more code and / or instructions or any combination or collection of code and / or instructions on a non-transitory processor-readable storage medium and / or a computer-readable storage medium that may be incorporated into a computer program product.

[0180] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method performed by a processor of an edge computing device to receive Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC), comprising: Sending a request for a manifest file of the DASH content to a server, wherein the DASH content is content formatted for streaming based on DASH; Receiving a response to the request from the server, the response including the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content; And Determining, at least in part based on parsing the manifest file, one or more DASH content components of the DASH content to be consumed; Selecting WebRTC, at least in part based on the indication that WebRTC can be used to deliver the DASH content, to receive the one or more DASH content components of the DASH content; And Sending a proposal to establish a WebRTC session to the server, the proposal including an indication of the one or more DASH content components of the DASH content.

2. The method according to claim 1, further comprising: Receiving an acceptance message to establish the WebRTC session from the server, wherein the acceptance message includes an object indicating a mapping between each respective media stream of the WebRTC session and the DASH content component assigned to that respective media stream among the one or more DASH content components of the DASH content.

3. The method according to claim 2, further comprising: Receiving the DASH content from the server via at least one respective media stream of the WebRTC session.

4. The method according to claim 1, wherein the proposal to establish the WebRTC session further includes an indication of one or more streaming attributes.

5. The method according to claim 4, wherein the one or more streaming attributes include one or more of bandwidth, width, height, frame rate, codec, and file type.

6. The method according to claim 1, wherein the indication that WebRTC can be used to deliver the DASH content includes an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in the WebRTC session.

7. The method according to claim 6, wherein the indication that WebRTC can be used to deliver the DASH content further includes an indication of a signaling protocol for use in establishing the WebRTC session.

8. The method according to claim 1, wherein the one or more DASH content components of the DASH content include one or more adaptive sets of the DASH content.

9. The method according to claim 1, wherein the manifest file of the DASH content is a Media Presentation Description.

10. The method according to claim 1, further comprising: Receive an indication from the server regarding an encryption context between Datagram Transport Layer Security (DTLS) and Secure Real-Time Transport Protocol (SRTP) that can be reused in a WebRTC session; Obtain a key for the DASH content from an encryption server in response to receiving an indication from the server regarding an encryption context between the shared encryption and DTLS-SRTP that can be reused in the WebRTC session; And Use the obtained key to decrypt the SRTP packet payload of the DASH content received in the WebRTC session.

11. A method performed by a processor of a server to deliver Hypertext Transfer Protocol-based Dynamic Adaptive Streaming over HTTP (DASH) content via Web Real-Time Communication (WebRTC), comprising: Send a reply to a request from an endpoint computing device for a manifest file of DASH content, where the DASH content is formatted to be streamed based on DASH, and where the reply includes the manifest file of the DASH content and an indication that WebRTC can be used to deliver the DASH content; and Wherein the indication that WebRTC can be used to deliver the DASH content includes an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in a WebRTC session.

12. The method of claim 11, wherein the indication that WebRTC can be used to deliver the DASH content further includes an indication of a signaling protocol for use in establishing the WebRTC session.

13. The method of claim 11, further comprising: Receive a proposal from the endpoint computing device to establish a WebRTC session, the proposal including an indication of one or more DASH content components of the DASH content; Establish the WebRTC session, the WebRTC session including a corresponding media stream for each of the indicated one or more DASH content components of the DASH content; Generate an object indicating a mapping between each corresponding media stream of the WebRTC session and the indicated DASH content component of the DASH content for that corresponding media stream; And Send an acceptance message to establish the WebRTC session to the endpoint computing device, where the acceptance message includes the object indicating the mapping.

14. The method of claim 13, further comprising: Use at least one corresponding media stream of the WebRTC session to deliver the DASH content to the endpoint computing device.

15. The method of claim 13, wherein the proposal from the endpoint computing device to establish the WebRTC session further includes an indication of one or more streaming attributes.

16. The method of claim 15, wherein the one or more streaming attributes include one or more of bandwidth, width, height, frame rate, codec, and file type.

17. The method according to claim 13, wherein the one or more DASH content components of the DASH content include one or more adaptive sets of the DASH content.

18. The method according to claim 11, wherein the manifest file of the DASH content is a media presentation description.

19. The method according to claim 11, further comprising: determining whether an encryption context between common encryption and Datagram Transport Layer Security (DTLS) of Secure Real-Time Transport Protocol (SRTP) (DTLS-SRTP) can be reused in a WebRTC session; and in response to determining that the encryption context between the common encryption and DTLS-SRTP can be reused in the WebRTC session: sending an indication to the endpoint computing device that the encryption context between the common encryption and DTLS-SRTP can be reused in the WebRTC session; and delivering the DASH content to the endpoint computing device without applying further encryption.

20. An endpoint computing device, comprising: a processor configured with processor-executable instructions for: sending a request for a manifest file of Dynamic Adaptive Streaming over HTTP (DASH) content to a server, wherein the DASH content is content formatted for streaming based on DASH; and receiving a reply to the request from the server, the reply including the manifest file of the DASH content and an indication that Web Real-Time Communication (WebRTC) can be used to deliver the DASH content; determining, at least in part based on parsing the manifest file, one or more DASH content components of the DASH content to be consumed; selecting WebRTC to receive the one or more DASH content components of the DASH content, at least in part based on the indication that WebRTC can be used to deliver the DASH content; and sending a proposal to the server to establish a WebRTC session, the proposal including an indication of the one or more DASH content components of the DASH content.

21. The endpoint computing device according to claim 20, wherein the processor is further configured with processor-executable instructions for: receiving an acceptance message to establish the WebRTC session from the server, wherein the acceptance message includes an object indicating a mapping between each respective media stream of the WebRTC session and the DASH content component assigned to that respective media stream among the one or more DASH content components of the DASH content.

22. The endpoint computing device according to claim 21, wherein the processor is further configured with processor-executable instructions for: receiving the DASH content from the server via at least one respective media stream of the WebRTC session.

23. A server, comprising: a processor configured with processor-executable instructions for: Send a reply to a request for a manifest file of Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) content from an endpoint computing device, where the DASH content is formatted for streaming based on DASH, and where the reply includes the manifest file of the DASH content and an indication that Web Real-Time Communication (WebRTC) can be used to deliver the DASH content; and where the indication that WebRTC can be used to deliver the DASH content includes an indication that the server has WebRTC capabilities and an indication of a signaling endpoint for use in a WebRTC session.

24. The server of claim 23, wherein the processor is further configured with processor-executable instructions to cause: the indication that WebRTC can be used to deliver the DASH content further includes an indication of a signaling protocol for use in establishing the WebRTC session.

25. The server of claim 23, wherein the processor is further configured with processor-executable instructions for the following operations: Receive a proposal to establish a WebRTC session from the endpoint computing device, the proposal including an indication of one or more DASH content components of the DASH content; Establish the WebRTC session, the WebRTC session including a corresponding media stream for each of the indicated one or more DASH content components of the DASH content; Generate an object indicating a mapping between each corresponding media stream of the WebRTC session and the DASH component assigned to that corresponding media stream in the DASH content; And Send an acceptance message to establish the WebRTC session to the endpoint computing device, where the acceptance message includes the object indicating the mapping.

26. The server of claim 25, wherein the processor is further configured with processor-executable instructions for the following operation: Use at least one corresponding media stream of the WebRTC session to deliver the DASH content to the endpoint computing device.

Images