Service Access Information - Periodically check for updated Service Access Information

[dsilhavy]

Feature description

TS 26.512 Section 4.7.2.3 defines the detailed procedure for updating the Service Access Information:

Once it has obtained an initial set of Service Access Information, the Media Session Handler shall periodically check for updated Service Access Information by issuing a conditional HTTP GET request containing either:

• an If-None-Match request header with the value of the entity tag (ETag) that was returned with the most recently acquired ServiceAccessInformation resource; or else
• an If-Modified-Since request header with the Last-Modified value of that most recently acquired resource. The periodicity of polling for updated Service Access Information shall be guided by the value of the Expires and/or Cache-control: max-age headers that shall be included along with every response message for this procedure.

TS 26.512 Section 6.2.3.4 defines support for conditional HTTP GET requests highlighting details about the responses from the 5GMS AF

All responses from the 5GMS AF that carry a resource message body shall include:

• a strong entity tag for the resource, conveyed in an ETag response header,
• a resource modification timestamp, conveyed in a Last-Modified response header, and
• a predicted time-to-live period for the resource, conveyed in a Cache-Control: max-age response header.

All API endpoints on the 5GMS AF that expose the HTTP GET method shall support conditional requests using the If- None-Match and If-Modified-Since request headers. API clients should not attempt to revalidate their cached copy of a resource using a conditional GET request before the indicated time-to-live period has elapsed.

Implementation

Implement the logic described above in the Media Session Handler. Currently, the Service Access Information is fetched only once at playback start never updated unless the streaming session is restarted.

[rjb1000]

@dsilhavy: I understand from @davidjwbbc that the currently released implementation of the 5GMS AF sets a time-to-live value of 60 seconds for the M5 Service Access Information resource. (This is statically configurable at runtime via the msaf.serverResponseCacheControl.m5_service_access_information_response_max_age parameter in the YAML configuration file for the 5GMS AF.) This should allow easy testing of your revalidation timer.

I believe that the response from the 5GMS AF already includes both Last-Modified and strong ETag headers as well as Cache-Control: max-age, as required by clause 6.2.3.4 quoted above.

[rjb1000]

While @davidjwbbc has developed proper support for conditional HTTP GET requests on this resource as part of 5G-MAG/rt-5gms-application-function#63, note that this code is not yet available on the development branch. There is a safe fallback position, however: if a server doesn't support conditional requests it can't return 304 Not Modified, and always returns 200 OK with the requested resource. This gives you a nice opportunity to make the reference Media Session Handler implementation more robust.

I would suggest storing the Last-Modified and strong ETag header values of the initial Service Access Information resource representation. When you revalidate the Service Access Information, but the 5GMS AF doesn't support conditional requests, it would be reasonable to compare the new Last-Modified and ETag header values of the 200 OK response with the previous ones.

1. If both Last-Modified and ETag are the same as before, it's a reasonable bet that the underlying Service Access Information resource hasn't changed, and you don't need to process the response body further.
   • You simply reset your timer to the value of Cache-Control: max-age to schedule the next revalidation.
2. If either (or both) Last-Modified and ETag have changed, you need to process the Service Access Information in the response body.
   • And you need to store those new Last-Modified and ETag values for next time, of course.
   • And reset the revalidation timer to the value of Cache-Control: max-age.

When we release the updated code implementing the conditional GET requests, you will be able to test your alternative code path for the 304 Not Modified response code. The handling for this response is essentially the same as case (1) above, just more explicitly signalled.

[dsilhavy]

The changes are addressed in #31 . My tests looked good, I also checked against the Linode instance. As pointed out by @rjb1000 the AF version on the Linode instance returns always 200 ok even when the ServiceAccessInformation did not change. By comparing last-modified and etag headers of the previous request to the current ones we avoid updating the internal representation of the ServiceAccessInformation in this case.

Detailed change logs can be found in #31.

[dsilhavy]

Released in version 1.0.2