DASH Manifest fetcher not persisting redirect URI after 302 redirection to CDN

[lukaszkalnik]

We had an issue with the DASH manifest fetcher not reusing the redirect URI after getting a 302.

The scenario is as follows (high traffic streaming platform using in-house streaming servers as entry point, which in case of a high load redirect the client to CDN):

1. Player requests manifest from the in-house server.
2. In-house server with a 302 redirects the player to a CDN server, where the player gets the manifest (Location URI is not set in the received manifest, as it is not mandatory).
3. After 2 seconds the player tries to fetch a new manifest, again from the in-house server instead of sticking to the CDN server assigned in the first call.
4. In a high traffic scenario obviously this leads to an overload on the in-house servers with too many continuous manifest requests from active players.

Setting the location URI in the manifest for the CDN servers would be impractical.

Is there something speaking against implementing a "sticky" behavior after a redirect for the manifest fetcher? The chunk source sticks correctly to the received URI, getting all chunks from assigned CDN server.
If such behavior cannot be made default, would it be possible to add a flag which activates it?

[lukaszkalnik]

I've done a bit of research and the issue seems to be related to how getting the URLs is handled for manifest and chunks. For manifest, Exoplayer always gets the URL from the original call in the ManifestFetcher (unless there is a Location tag in the manifest, which is not the case here). For chunks on the other hand Exoplayer gets the url from the currently open connection in the DefaultHttpDataSource.

Would there be a possibility to customize/change the behavior somehow? Maybe using the MediaPresentationDescription.location field (which is used currently to support the Location manifest tag)?

[ojw28]

It's kind of unclear what the expected behavior should be. I can envisage some services not wanting the sticky behaviour. It seems preferable to get a definitive answer (e.g. an addition to the DASHIF interoperability document), rather than adding a player option...

[ojw28]

Closing since no further information was provided, and since I'm not aware of any specification or interoperability point that indicates sticky behaviour is the right thing to do.

I also don't think it's impractical to come up with a serving solution that avoids the issue described. For example, in the steps described above, the player must have obtained a URL before the first step. You could perform the redirect at that point. The player would already have an appropriate CDN URL at step 1, and could just use that directly.