Handling of absolute <BaseURL> elements

[dsilhavy]

Description

While implementing Docker support for the Application Function and the Application Server, we stumbled upon the following question regarding the handling of absolute URLs inside <BaseURL> elements in a DASH MPD.

As an example the following MPD is available on an origin: https://rdmedia.bbc.co.uk/elephants_dream/1/client_manifest-all.mpd. This MPD uses an absolute URL inside the <BaseURL> element:

<BaseURL serviceLocation="A" dvb:priority="1" dvb:weight="1">https://vod-dash-ww-rd-live.akamaized.net/elephants_dream/1/</BaseURL>

Now assume we use the following content hosting configuration to configure the Application Server via the M1 interface of the Application Function:

{
    "name": "BBC R&D Demo Streams",
    "ingestConfiguration": {
        "pull": true,
        "protocol": "urn:3gpp:5gms:content-protocol:http-pull-ingest",
        "baseURL": "https://rdmedia.bbc.co.uk/"
    },
    "distributionConfigurations": [
        {
            "entryPoint": {
                "relativePath": "elephants_dream/1/client_manifest-all.mpd",
                "contentType": "application/dash+xml",
                "profiles": ["urn:mpeg:dash:profile:isoff-live:2011"]
			}
        }
    ]
}

This results in a Service Access Information like this:

{
    "provisioningSessionId": "40acd660-b300-41ef-b896-0970c67f805c",
    "provisioningSessionType": "DOWNLINK",
    "streamingAccess": {
        "entryPoints": [
            {
                "locator": "http://localhost/m4d/provisioning-session-40acd660-b300-41ef-b896-0970c67f805c/elephants_dream/1/client_manifest-all.mpd",
                "contentType": "application/dash+xml",
                "profiles": [
                    "urn:mpeg:dash:profile:isoff-live:2011"
                ]
            }
        ]
    }
}

A 5GMS client will use the URL defined in locator to fetch the MPD. The locator URL points to the Application Server (M4 interface). Without any modification by the Application Server, the MPD still contains an absolute BaseURL:

<BaseURL serviceLocation="A" dvb:priority="1" dvb:weight="1">https://vod-dash-ww-rd-live.akamaized.net/elephants_dream/1/</BaseURL>

All subsequent requests to media segments performed by the media player will go directly to the origin and not through the Application Server.

The main question is if the origin content with an absolute <BaseURL> is valid and if the Application Server is supposed to account for such content. For instance by removing or editing the <BaseURL>.

[dsilhavy]

Note: We can transfer this issue into a discussion thread or move it to the Standards repo if required.

[rjb1000]

Some initial thoughts about this:

1. Absolute base URLs in the presentation manifest anchor the content to a particular origin server and make the presentation non-portable.
   • This is bad news for reverse proxies such as CDNs and the 5GMSd AS.
   • Generally speaking, absolute base URLs are best avoided in presentation manifests.
2. When absolute base URLs are present in presentation manifests, a reverse proxy needs to rewrite the manifest so that subsequent content requests go to the reverse proxy and not back to the origin server.
   • As an implementation choice, the base URLs can be rewritten as absolute URLs pointing to the reverse proxy, or else as URLs relative to the URL of the manifest.
3. Presentation manifest rewriting is a candidate for the content preparation feature of the 5GMS AS.
   • The manipulation would be specified in a Content Preparation Template that is provisioned at reference point M1.
4. As of Release 18, TS 26.512 does not specify any concrete Content Preparation Template formats.
5. The Release 19 feasibility study "FS_AMD" recommended looking into Content Preparation Templates in the context of a Key Issue on multi-CDN media delivery, and it is likely that something will be specified normatively in the next year. However, this might be more of a point solution for CMMF rather than a general solution.
   • For the general direction of travel, see new clause 5.19.3.2.1 in agreed TR 26.804 CR0024r1 in S4-242235. Also conclusion 2b in clause 5.19.7 and recommendations 7 and 12 in clause 6.19.
6. For the time being, the 5GMSd AS reference implementation does not support MPD rewriting.
   • The reference implementation is based on Release 17, which is silent on this topic.
   • There may be an argument that rewriting absolute base URLs in presentation manifests could be an implementation-specific feature of a 5GMSd AS prior to Release 19 without the need for any Content Preparation Template.
7. For the time being, the best practical advice is to use only DASH MPDs that contain relative URLs with the reference 5GMSd AS implementation.