Lumen help

Frequently asked questions about Application and Content Delivery services

General questions

Web integrations can be as simple as adding a few lines of code to the player, while mobile SDKs generally take up to a day to fully integrate. We generally recommend the following timeline:

 

  • Web & mobile Integration​: 20 minutes to 2 hours​

  • Configuration & QA testing: 3 hours

  • Staging / production tests: Test on a subset of users​ - 1 day to 1 week. For complex workflows, we recommend one week so that we can gather metrics, identify any bugs, tweak configurations and optimize delivery.

  • Production rollout: deploy progressively across your entire user base with our ramp-up tool​ – 4 hours to 1 day​

 

Our integration team is at your disposal to assist you across the integration, testing and rollout phases.

Yes, each platform has its own integration. Our expert integration team is at your disposal to assist you in that process.

The following table provides a non-exhaustive list of compatible workflows.

Encoding
Security
CDN
Web Players
Native Platforms
SSAI
Analytics
Any
Widevine
Any
Vimeo
Dash.js
Android & Android TV - Exoplayer
Yospace
Conviva

Playready

Bitmovin
Hls.js
Android & Android TV - THEOplayer
Google DAI
Youbora

Fairplay

Kaltura
Video.js
iOS, tPadOS, tvOS - AVPlayer
Ad Insertion Platform
Luna

BuyDRM

Brightcove
Shaka Player
Roku AWS Media Tailor
Bitmovin

AES 128

JW Player
Flowplayer
Universal Windows Platform (UWP)
  Mux

 
THEOplayer
Clappr
Comcast RDK
  Cedexis

 
Castlabs
Radiant Media Player     Google

 
Comcast
Mpx     Fastly

 
Azure Media Player
Akamai Adaptive Media Player
     

Lumen Technologies acquired Streamroot in 2019, which led to renaming of our products. Please refer to the following table for clarification on the name changes:

Name

Abbreviation(s)

Alternative Name(s)

Description

Lumen Mesh SDK

 

Mesh SDK, Streamroot SDK

The native SDK for Mesh Delivery

Lumen CDN Load Balancer SDK

 

 

The native SDK for CDN Load Balancer

Web SDK

 

Streamrooter

The web SDK for both Mesh Delivery and CDN Load Balancer

Delivery Client Key

dcKey, srKey

Streamroot Key

The unique security key assigned to you

Lumen Delivery Client

LMDeliveryClient

DNA Client

The runtime object instance at client-side

Peer-Agent

 

 

The P2P core library for Mesh Delivery

Mesh Delivery for Streaming

Connections between peers are done via a secure webRTC Data Channel (DTLS encrypted). Segments integrity is checked via checksum to avoid content tampering.
 

SRTP (Secure Real-Time Transport) is used for the transport of video and audio streams. SCTP (Stream Control Transport Protocol), is used for the exchange of application data.

Mesh Delivery is agnostic to DRM, as it operates at the network level. Packets are transferred as-is.

If you run many DRM providers at the same time, the content URLs must be different for peer-to-peer to work correctly (clustered per DRM provider).

It is configurable via the dashboard. Customers can decide to enable or disable peer-to-peer for viewers on mobile network or Wi-Fi.

While we are not an analytics platform, our dashboard displays basic metrics such as CDN offload, traffic volume, sessions, concurrent viewers, bandwidth and rebuffering. Splits and filters are also available.

You can schedule automatic reports on any metric to be sent to a configurable list of recipients.

If you encounter the following message after displaying the Mesh Delivery graph, it means that Mesh Delivery is not activated on this specific  webpage.

Mesh is not activated

There are several reasons you may see this message:
 

  • Verify your browser compatibility. Mesh Delivery does not support Internet Explorer and legacy Edge browser. While Mesh Delivery works on older versions of Chrome, Firefox, Edge, and Opera, we strongly recommend updating your browser to the latest version to get the most out of Mesh Delivery.

  • Make sure you enter the correct Streamroot Key. You can find it in the 'Account' section of the dashboard.

  • Make sure that you are using a compatible player and that it has been properly configured based on our documentation.

If you are unable to connect to any Mesh Delivery sources, i.e., after displaying the Mesh Delivery graph, you see Sources: 0, check the following to troubleshoot.
 

Open the developer tool of your browser and navigate to the 'Network' tab. Filter requests by host "backend.dna-delivery.com" and examine the following requests.
 

  1. https://backend.dna-delivery.com/<AZ>/distributor/<VERSION>/config/web

    1.  Returns an HTTP status code of 200 - Success

      1. if backendCounts.contentActivated is false , tyour stream doesn't meet the conditions set in your activation threshold settings. This setting determines the minimum number of viewers per stream for Mesh Delivery to be activated. Please contact us for further information or to customize this setting.

      2. If  propertyParameters.activationRatio is not set to 1, it means an Activation Ratio has been set in the Property used.

      3. If bypassed is true, it means our support team has deactivated Mesh Delivery for security reasons. Please contact us for further information.
         
    2. If the request returns a status code of 403 - Forbidden with message "domain name not allowed", it means that a whitelisted domain name has been added in your dashboard to secure your Streamroot Key, and the website on which you are playing the video does not match it.

    3. If the request returns a status code of 403 - Forbidden with message "audience limit reached",  it means you have exceeded the maximum number of viewers allowed in your plan. Please contact us for further information.
       
  2. https://backend.dna-delivery.com/<AZ>/secure/[...]

    1. Returns an HTTP status code of 200 - Success

If either of these two requests fail, please contact cdnsupport@lumen.com.
 

Please note that some custom configurations may show a different host than the default backend.dna-delivery.com. The path remains the same.

Mesh Delivery matches together viewers in real-time according to many criteria. The algorithm’s goal is to connect together viewers that can provide the highest CDN offload.
 

Matching criteria include:
 

  • Intrinsic to the stream itself, enabling content share: content identifier, video quality track, playback position, etc.

  • Related to the peer connection, aims at maximizing CDN offload: Internet Service Provider (ISP), Autonomous System Number (ASN), Geography, etc.
     

During the PoC phase, we adapt the matching configuration to satisfy customer needs. For example, it is possible to restrict the peers’ connection within an ISP, to reduce the Mesh traffic going through ISP peering or Internet Exchange points.
 

In addition to this, our client-side module can dynamically adapt to network conditions and promote seeding peers which demonstrate the best performance and demote the ones that generate connections errors or demonstrate slow network speed.

Any video P2P solution relies on two groups of users:
 

  • Seeders: preferably download segments of the video from the CDN, store them in a P2P cache and send sub-portions of them, named chunks, to other peers.

  • Leechers: preferably download the chunks from the seeders, over the P2P network.
     

In any of the two cases, if the segment in the P2P cache is not complete when the media engine requests it, Mesh Delivery fallbacks to a request to the CDN, in order to avoid rebuffering. Mesh Delivery doesn’t do new segment requests to the CDN by its own; it completely relies on the player’s logic.
 

To induce the player to request more segments from the CDN in advance - so that they could be shared in the P2P network before the leecher’s player requests it -  we leverage the player’s APIs to increase the player buffer target levels. Especially in live use-cases, seeders are set with a “high player buffer target”, whereas leechers with a smaller one. The player buffer target should not exceed the latency (a.k.a. distance of playback to the live edge).

We operate on the vast majority of network topologies. In some particularly complex cases we might need some adaptations, in which case our dedicated team can support you on tweaking your configuration.

High QoS for the end user is our priority and we tune our configuration to achieve this and not impact end-user experience.

We track many QoS metrics via our powerful internal analytics platform; this allows us to tune the peer-to-peer module configuration towards the highest possible levels of QoS and offload, tailored to each customer need.

In addition, the peer-to-peer module adapts in real-time to the device’s capabilities (CPU, RAM, battery) and network speed, in order to guarantee the same levels of QoS of a vanilla player.

Lastly, by loading the peer-to-peer module asynchronously, we make sure the video startup time is not affected as well.

Mesh Delivery for Enterprise

Mesh Delivery for Enterprise adds:

  • Capability to restrict the peer-to-peer traffic within a corporate office or IP subnet

  • Support of Microsoft Teams and Stream

  • dedicated troubleshooting tools
     

All other features are equivalent to Mesh Delivery for Streaming.

The platform comes with basic tools to enable auto location isolation such as isolating peering over ISPs, and it is also possible to isolate by public IPs, subnets, and IP masks.

CDN Load Balancer

Calculating the Global CDN score

 

CDN Load Balancer bases its selection and switching decisions on a "global" score. In practice,

Global score = business score * QoS score

The global score is based on:

  1. A business score provided by the broadcaster: This business score reflects how heavily commit-based or business-based inputs should be evaluated; it can take integer values of 1 to 100.

  2. A Quality of Service score: At the beginning  of the session, the QoS score is calculated from the metrics CDN Load Balancer gathers from across the broadcaster's user base. During the session, the QoS score is the quality perceived by the end-user device during the session: bandwidth, time to first byte, and error rate.

After the beginning of the session, quality is calculated locally. This prevents CDN Load balancer from becoming a single point of failure; during the session, CDN Load Balancer only connects to the backend to send quality statistics to be ued in initial scoring for future sessions.

Practical Example

 

A broadcaster uses three CDNs for delivery on the West Coast of the US. CDN A is its primary delivery network with CDN B and CDN C as backups. It assigns each CDN the following business scores:

 

CDN A: 8     CDN B: 4        CDN C: 2       

 

In this case, CDN A will be chosen except when CDN B's quality of service is more than twice as high as that privded by CDN A. In practice, this means significantly lower bandwidth or prevalent errors. By the same token, CDN C will not be used unless its QoS is more than twice as high as CDN B, and CDN A is not available.

 

The business score for a CDN can be changed at any time and is reflected on new and already running sessions less than a minute after the update in the dashboard.

For example, this allows you to modify CDN priority if you reach one of your CDN commits during the month.