Menu

Lumen help

Frequently asked questions about Application and Content Delivery services

Here you will find answers to some frequently asked questions for our products.

General questions
Mesh Delivery for Enterprise
CDN Load Balancer
Mesh Delivery for Streaming

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.

Client code is released on a quarterly basis. Hotfixes can be released at any time.
 

Web: update of the code is automatic as assets are generally loaded dynamically when you're using our CDN delivery.

Native: the customer needs manual action to upgrade the libraries.


We suggest customers to upgrade regularly to get the latest features and best performance. More information on updates can be found here.

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

Yes. For our products’ data privacy sheets and information on processing of Personally Identifiable Information (PIIs), please visit our trust center for more details.

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.