Enable beacon reporting of CMCD data in the event that the player cannot contact the CDN

[wilaw]

The transmission of CMCD data assumes that the player can request content from the CDN. A use-case arises in which a distributor is using CMCD as the basis for their visibility solution and the player is unable to retrieve content from the CDN. How would it notify the distributor of this fact?

Some proposals:

1. The player is configured with a CMCD beacon URL. This is provided by the distributor. It may be provisioned by the CDN(s) but ideally would be independent.
2. In the event of receiving an error (defined below), it would make a GET or HEAD call to this beacon and pass along CMCD 'requestError' fields as either headers or query args.
3. Error types
   1. Non 2xx, 3xx response codes - i.e 404, 503 etc.
   2. No response code at all - timed out.
   3. Request error syntax - key name 're', value = STRING formatted as ;; where is the session-id the player had established for that playback session, is the HTTP response code received, or empty-string if none was received, and is the path of the request that failed.

Example:

1. The distributor creates a beacon service at https://realtime-monitoring.coolvideos.com/cmcd-request-errors. This is given to the player and initialized by the players setCMCDErrorBeacon() API.
2. The player attempts to request https://cdn1.com/playlist.m3u8. It receives a 404.
3. It prepares the error payload string as re="kj3h45j34hh3fnk3j4hfkn3j4h;404;https://cdn1.com/playlist.m3u8"
4. It then makes a GET or HEAD request to https://realtime-monitoring.coolvideos.com/cmcd-request-errors?CMCD=re%3D%22kj3h45j34hh3fnk3j4hfkn3j4h%3B404%3Bhttps%3A%2F%2Fcdn1.com%2Fplaylist.m3u8%22

[glenng1215gh]

I agree that an approach like this is important for errors, but that we also need a more robust definition of beacons for out-of-band QOE reporting. Created a new GIT Issue on this: #113