This guide outlines the mandatory pre-requisites for fully migrating your live streams from MSL4 to MSL5 (Final Phase). Please verify all conditions and finalize migration before MSL4 reaches End of Life (EOL).

• Target audience. Whether you've previously implemented a soft migration or a hard migration, this guide supports your journey to complete the migration to MSL5 Phase 3.
• Requirements. The final migration requires that all dependent systems—the encoder configuration, network firewall, and CDN configuration—are reconfigured to work with MSL5 before the cutover.
• Important Note. Failure to address any of these prerequisites will result in ingest failure, playback degradation, or CDN pull errors after migration.

Encoder Configuration Update

Changes

MSL4 streams are published to an Akamai-managed ingest entrypoint. MSL5 uses a separate entrypoint domain managed under MSL5 infrastructure.

Action Required

Reconfigure the customer encoder to publish the HLS-push/CMAF-push stream over HTTPS to the new MSL5 entrypoint URL.

Review this example where 50002 is the numeric stream ID assigned during MSL5 provisioning. Numeric stream ID are typically 5-8 digits in length.

• MSL5 Primary Ingest: <https://p-ep50002.i.mslentrypoint.net/50002/event1/master.m3u8>
• MSL5 Backup Ingest: <https://b-ep50002.i.mslentrypoint.net/50002/event1/master.m3u8>

📘

The event name and segment paths are typically preserved during migration — only the domain and entrypoint hostname change. You need to verify the exact MSL5 ingest URLs with the MSL5 provisioning team before encoder cutover.

Network Firewall — Egress Allow Rule for MSL5 Domain

Customer encoders commonly sit behind a corporate or datacenter firewall with restrictive egress rules that only allow outbound connections to explicitly approved domains. Because MSL4 and MSL5 use different domains, the existing MSL4 allow rule does not cover MSL5 ingest.

Action Required

Before migration, the customer's network/firewall team must add an egress allow rule for:

Destination domain: *.mslentrypoint.net
Ports:              TCP 443 (HTTPS push) and TCP 80 (HTTP push, if required)
Direction:          Outbound (encoder → MSL5 entrypoint)

🚧

This firewall change must be made and verified before the encoder is pointed at the MSL5 entrypoint. If the firewall is not updated first, the encoder will fail to connect after cutover and the stream will go dark.

Verification

After the firewall rule is in place, verify connectivity from the encoder host before the production cutover.

# Test HTTPS connectivity to MSL5 entrypoint (replace with actual entrypoint hostname)
curl -sv --max-time 5 https://p-ep50002.i.mslentrypoint.net/ 2>&1 | grep -E 'Connected|SSL|HTTP'
 
# If using port 80
curl -sv --max-time 5 http://p-ep50002.i.mslentrypoint.net/ 2>&1 | grep 'Connected'

A TCP connection (even a non-200 HTTP response) confirms the firewall is open. A Connection refused or timeout indicates the egress rule is still missing.

CDN Configuration — Akamai AMD Property for Redundant MSL5 Origins

MSL5 outputs content via an origin infrastructure that exposes separate origin hostnames for primary and backup regions. Unlike MSL4, which allowed customers to operate with a single primary origin hostname, MSL5 requires the CDN to be configured with both a primary and a backup origin to achieve the equivalent high availability. Customers who only configured a primary origin in MSL4 must add the backup origin definition in MSL5.

Reference: Configure AMD Property for Redundant MSL5 Origins

Stream Path Convention

MSL5 stream IDs are numeric and typically 5–8 digits in length. The backup ingest path appends -b directly to the numeric stream ID.

The -b suffix on the numeric stream ID identifies backup-ingested content. The Akamai AMD property must be configured so that requests for /{streamid}-b/ paths are forwarded to the backup origin host, not the primary.

Primary and Backup Origin Hosts

MSL5 origin hostnames follow the format {region}-{originName}.mslorigin.net. The region and origin name are assigned during MSL5 provisioning.

The origin name component such as myorigin is customer-specific and provided in the MSL5 provisioning output. Primary and backup origins are typically in different geographic regions for resilience.

In the Akamai AMD property, configure two origin definitions — one for primary and one for backup — and use a match rule on the request path to select the correct origin:

• Requests with URL path matching /{streamid}-b/. For example, /50002-b/) → route to Backup Origin Host
• All other requests → route to Primary Origin Host

MSL4 customers with single-origin configuration. If your MSL4 AMD property was configured with only a primary origin (no backup origin definition), you must add the backup origin definition for MSL5. Operating MSL5 with only a primary origin eliminates the redundancy that the backup ingest entrypoint provides.

AMD Origin Type Configuration

In MSL4, the AMD property selects the MSL4 origin automatically within the same Akamai account — no explicit origin hostname entry is required. In MSL5, the origin is no longer an in-account Akamai-managed resource. The AMD property must be reconfigured to use the "Your Origin" origin type and the MSL5 origin hostname must be entered explicitly.

Update the following in the AMD property for each origin definition (primary and backup).

G2O (Ghost to Origin) Authentication

MSL5 origins require G2O authentication to ensure only authorized Akamai edge/mid-tier servers can pull content from the origin. G2O is a shared-secret HMAC-based authentication mechanism. Refer to MSL4 Origin and MSL5 Origin Integration with AMD Property for details.

Update G2O configuration for both primary and backup origin definitions in the AMD property.

📘

MSL4 and MSL5 G2O keys are not shared. Even if the stream IDs are preserved, a new G2O key must be retrieved from the MSL5 configuration and applied to the AMD property before cutover. Using an invalid G2O key will cause all CDN origin pulls to return 403 Forbidden.

MSL4 Origin and MSL5 Origin Integration with AMD Property

MSL4 Origin Integration with AMD

MSL4 Origin has a tightly integrated authentication mechanism with AMD properties. This means that users do not need to manually enter the MSL4 Origin authentication key when configuring the AMD property. The authentication configuration is handled automatically, ensuring a seamless setup experience for users.

MSL5 Origin Integration with AMD

MSL5 Origin, which replaces MSL4 Origin, does not maintain the same level of tight integration with AMD. Instead, Origin Type “Your Origin” should be used and authentication is exposed for user to configure. This requires users to manually input authentication credentials when setting up the MSL5 Origin.

Additionally, for MSL5 Origin and AMD to function together with origin G2O authentication [​Akamai​ Signature Authentication], users must configure the AMD property using the same credentials. This manual configuration ensures that authentication between MSL5 Origin and AMD is properly synchronized.

Summary of Changes:

• MSL4 Origin. Tight integration with AMD; no need for manual authentication key entry.
• MSL5 Origin. Requires manual authentication configuration.
• AMD Property Configuration. Users must enter the same credentials for MSL5 Origin and AMD to work together with origin G2O authentication.

These changes provide greater flexibility in authentication management while requiring users to manually configure authentication details for MSL5 Origin and AMD integration.

Comparison Diagram

This diagram visually represents the differences in authentication handling between MSL4 and MSL5 Origins when integrated with AMD.

Best Practice — Test in Staging

• Validate the Setup. Before the cutover, update your new MSL5 origin in staging on your AMD configuration and test the MSL5 setup end-to-end.
• Handle URL Changes. If you need to use the new MSL5 playback URL (with a new stream ID), you can handle this by using a rewrite rule in your AMD configuration.
• Rapid Iteration. In 10 minutes, you’ll have a new MSL5 stream and an updated AMD property version. This gives you the flexibility to validate MSL5 and refine the configuration before updating the encoder for production.
• Encoder and AMD updates do not need to be synchronous. You can update them independently, and you do not need to change both at the same time.

Pre-Migration Validation Sequence

Perform validation in the order as shown in the table below to catch issues before the production cutover.

Summary of Key Migration Changes: MSL4 vs MSL5