eCDN FAQ

[collapsed title="What is (Kaltura Edge Server) KES?"]

 

The Kaltura Edge Server is a proxy cache server running in your corporate network behind your firewall that downloads and caches the video stream contents. It then acts as the content origin for the video player clients in that location. You may have multiple eCDN server instances.

The Kaltura Edge Server belongs to a location, and acts as a local cache for that location. Each eCDN Kaltura Edge Server instance requires only outbound network connectivity to the Internet. There are no inbound connections from the Internet to the eCDN servers.

The Kaltura Edge Server (KES) is an Nginx-based component that brings content closer to the end-users. The KES has the following capabilities:

  • fetch from origin
  • pre-positioning
  • HLS stream segmenting

and more.

In its simplest deployment design, the KES will fetch VOD and live assets from Kaltura SaaS and serve them to the end-users or additional KESs in a tiered design.

[/collapsed]

[collapsed title="What are the standard KES System Requirements?"]

  • 4 CPU cores
  • 8Gb Memory
  • 100Gb storage
  • Access to an up-to-date repository for Centos/RHEL packages
  • For 500 concurrent users 1Gb LAN connection (dedicated)
  • For 5000 concurrent users 10Gb LAN connection (dedicated)

[/collapsed]

[collapsed title="How does pre-positioning work?"]

 

Each KES is configured with a playlist id. You can only configure one playlist per KES. There is a schedule that is set where it will download the items from the playlist at the specified time. You can also limit the bandwidth that is used to download these assets. These assets are placed directly on the KES node.

[/collapsed]

[collapsed title="How does end-user detection work?"]

 

When an end-user makes a request for the player manifest (playManifest), the Kaltura Cloud maps the partner ID and external IP address that made the request. If an additional custom header is passed along with the internet IP address, an additional mapping is applied. Typically, the additional custom header is utilized in the hub-spoke model of multiple offices feeding through one common data center.

[/collapsed]

[collapsed title="What URLs does an end-user access when playing back?"]

  • stats.kaltura.com
  • analytics.kaltura.com
  • cfvod.kaltura.com
  • cdnapisec.kaltura.com
  • klive-a.akamaihd.net
  • klive.kaltura.com
  • fstlive.kaltura.com

Note: Many of these URLs are CDN-based. Kaltura cannot provide static IP addresses for firewall/proxy exceptions.

[/collapsed]

[collapsed title="What URLs does the KES access?"]

Please refer to eCDN Whitelist URLs and IPs

[/collapsed]

[collapsed title="What player uiconf modifications are required to playback from KES??"]

None

[/collapsed]

[collapsed title="When and where are SSL certificates required?"]

SSL certificates are always required to ensure video playback can be done on HTTPS. When mobile support is not required, certificates can be self-signed by the customer. For iOS and Android, publicly signed certificates are mandatory.

[/collapsed]

[collapsed title="How does the KES failover?"]

The KES sends a heartbeat every 60 seconds, and when a new play manifest is requested by the player, the platform verifies if it received a heartbeat in the past 180 seconds. If no heartbeat was received, then it will use the configured KES fallback server. If no KES fallback server is configured, it will fall back to the default Kaltura CDN,  if it was configured to do so. If it was not configured to use the Kaltura CDN, then the video will fail playback.

[/collapsed]

[collapsed title="How does the KES scale?"]

Currently, the platform does not act upon KES health stats such as CPU/memory/network utilization and divert traffic to healthier nodes. If it is needed to scale past the current KES's resource capabilities,the followingoptions may be considered:

  1. Multiple KES servers can be configured for a single location, causing the load to spread out evenly.
  2. Segment the IP address ranges further across multiple KES servers.
  3. Utilize a Load Balancer in front of two or more KES servers (not recommended)

[/collapsed]

[collapsed title="Is there a limit to the number of rules per KES, or in total?"]

Due to processing considerations, the complete set of routing rules for an account cannot exceed 16 megabytes. In most cases, this is sufficient for well over 100,000 rules. There is no separate limit to the number of rules for a single KES.

If you plan to use more than 100,000 rules, please consult with your assigned Kaltura engineer or with Kaltura Customer Care.

[/collapsed]

[collapsed title="Can the KES operate without an Internet connection?"]

No. KES and all playback of video require the ability to make connections to Kaltura Cloud.

[/collapsed]

[collapsed title="Can the KES do tokenization or AES-128 encryption?"]

Not currently available, a product enhancement request can be opened if this is required.

[/collapsed]

[collapsed title="Can the KES serve from remote storage?"]

Yes

[/collapsed]

[collapsed title="How do I view the status or health of the KES node?"]

There is a monitoring dashboard available on https://ecdn-monitor.kaltura.com. Login is done with Administrator level KMC login details (every KMC user can login here).

[/collapsed]

[collapsed title="How do I add/modify/delete IP addresses for the end-user mapping function?"]

The ability to add/modify/delete IP addresses is via a non-customer-facing control panel. Modifying via API calls is very complex, and the control panel is the highly recommended way to do these tasks.

A customer facing version of this control panel is available on https://kaltura.io/dashboard/ and training is provided to customers during the deployment project.

[/collapsed]

[collapsed title="Who is responsible for updating the operating system on the KES node?"]

Unless specified in pre-sales, the customer is responsible for updating the operating system with normal and typical security patches. Kaltura will provide and update any KES related software patches.

[/collapsed]

[collapsed title="How will KSS/KES upgrades or patches be performed?"]

KSS and KES upgrades/patches are performed via command-line and by Kaltura Professional Services. We currently do not offer a supported method for customers to perform these upgrades/patches by themselves.

[/collapsed]

[collapsed title="How can I tell if eCDN is working?"]

This can be verified by the "Network" tab in the browser such as Chrome, Firefox, or IE. After clicking Play, you should see a stream of requests passing via the KES.

[/collapsed]

[collapsed title="How does eCDN work with WAN optimizers like Bluecoat and Riverbed?"]

WAN Optimizers such as Bluecoat and Riverbed take advantage of byte-level and object caching for VOD assets, and stream-splitting for live assets via HLS. Tokenized URLs are cached via the byte-level caching, where they would otherwise be missed with object caching. Stream-splitting is a feature that the customer needs to enable on Bluecoat/Riverbed to detect the .TS segments and perform the proper locks on the stream.

[/collapsed]

[collapsed title="Does KES work with Kaltura's Webcasting feature?"]

KES and KSS support the full range of Kaltura Live capabilities. Capabilities with partner solutions such a RAMP for multicast may be limited.

[/collapsed]

[collapsed title="What end-user information is passed to Kaltura when using eCDN?"]

When an end-user accesses Mediaspace, and plays back a video, the end-user makes 4 connections:

  1. To your SSO system. (If applicable)
  2. To the Kaltura CDN for widgets, player objects, related files, etc.
  3. To Kaltura Mediaspace for the actual Mediaspace web application
  4. To the Kaltura Edge Server (KES) for playback of the video assets. The Kaltura Edge Server then passes the request back to Kaltura’s CDN which contains the video asset unique IDs and video segment number.

The end-user data that would be sent to the Kaltura cloud in that scenario would be the following:

  1. SSO Attributes that you choose to send to the end-user from your SSO system. The user then POSTs it to Kaltura’s Mediaspace server who then validates it prior to allowing the user access. These attributes would typically include firstname, lastname, email address, role, and any groups. This is the nature of SSO so that you only send what info you want, and no passwords or sensitive data is passed to our system.
  2. The end-user external(public) IP address. If accessing via an office or central datacenter, it would be their public IP address.
  3. The end-user Internal IP address when using an eCDN hub-spoke topology. Kaltura uses the end-user Internal IP address to form a “mapping” between the external and internal IP address to identify which sub-office the end-user is located in. Again, picture a hub-spoke topology where multiple offices internet traffic all flows through a central datacenter before reaching the Internet. If you don’t have this hub-spoke topology and all offices have independent Internet connections, then Kaltura only needs the external(public) IP address to “enable” the eCDN component.
  4. End-user browser information (no different than a typical webpage session)

[/collapsed]

Network and Firewall White List Requirements and Explanations

The Kaltura Edge Server utilizes the following network ports and domains.

 

Port

Source

Destination

Domain

443

Internal User

Kaltura Edge Server

 

80

Internal User

Kaltura Edge Server

 

443

Kaltura Edge Server

Kaltura Cloud

https://*.kaltura.com

If no wildcards allowed, then;

cfvod.kaltura.com

cdnapi.kaltura.com

klive.kaltura.com

www.kaltura.com

fstlive.kaltura.com

cdnapisec.kaltura.com

fstlive.kaltura.com

ecdnmonitor.kaltura.com

 

https:///kalsegsec-a.akamaihd.net

(Alternative CDN domain)

 

https://klive-a.akamaihd.net

(Legacy Live CDN)

 

https://kalseglive-a.akamaihd.net

(Alternative Live CDN)

 

https://*.kaltura.io

(RPM repository and file exchange)

http://*.kaltura.org

 

80

Kaltura Edge Server

Kaltura Cloud

http://*.kaltura.com

If no wildcards allowed, then;

cfvod.kaltura.com

cdnapi.kaltura.com

klive.kaltura.com

www.kaltura.com

fstlive.kaltura.com

cdnapisec.kaltura.com

fstlive.kaltura.com

ecdnmonitor.kaltura.com

22

Administrator

Kaltura Edge Server

 

 

In This Article